Fedora and fallback DNS servers [LWN.net]

Fedora and fallback DNS servers

Posted Feb 26, 2021 6:49 UTC (Fri) by roc (subscriber, #30627)
In reply to: Fedora and fallback DNS servers by Sesse
Parent article: Fedora and fallback DNS servers

Where?

The guy who owns the Gecko HTML5 parser is VERY diligent about avoiding this sort of thing. I can let him know.

to post comments

Fedora and fallback DNS servers

Posted Feb 26, 2021 7:29 UTC (Fri) by Sesse (subscriber, #53779) [Link] (1 responses)

I no longer have access to the code in question, sorry. The point is that even in HTML5, you cannot assume consistent bug-by-bug compatibility of tag soup parsing.

Fedora and fallback DNS servers

Posted Feb 26, 2021 11:10 UTC (Fri) by roc (subscriber, #30627) [Link]

If you say so, but FWIW, my impression is that HTML parsing differences are far down the list of issues that cause compatibility problems.

Fedora and fallback DNS servers

Posted Feb 26, 2021 14:25 UTC (Fri) by jkingweb (subscriber, #113039) [Link] (1 responses)

My own experience agrees with this. Last year I found a bug in the Encoding spec test suite, which resulted in bugs being filed for Gecko, WebKit, and Chromium, because they passed the incorrect test. The Gecko and WebKit bugs were fixes promptly. The Chromium bug, unsurprisingly, is still open. They don't seem to care whether they decode characters the same as everyone else (they have tons of decoder bugs), so I wouldn't be surprised if that extends up to parsing chain. Mozilla, though? Doesn't seem to be a problem.

Maybe Sesse was referring to code which predated the parsing test suite, however.

Fedora and fallback DNS servers

Posted Feb 26, 2021 15:57 UTC (Fri) by excors (subscriber, #95769) [Link]

If I remember correctly, there is very little "code which predated the [HTML5] parsing test suite" - the first reasonably-comprehensive test suites (including tests for a lot of the error handling) were developed in parallel with the first public parser implementation (html5lib, I think?) and in parallel with the specification itself. That was valuable for detecting and fixing any unspecified or ambiguous behaviour in the specification, and then the specification plus test suites were a strong foundation for the subsequent browser implementations, which at least in Mozilla's case was basically a from-scratch rewrite.

I'm sure it wasn't perfect and there were still bugs, and probably things have changed a lot since I last looked at it seriously (a worryingly large number of years ago), but my impression at the time was that it was very successful at achieving interoperability across all the browsers and several non-browser parser implementations. (And it was enormously more successful than HTML4's approach of "here's the specification of a valid document, and how browsers should handle it. Huh, invalid document? Why would anyone do that? Just fix your document" and XHTML's approach of "Invalid document? YELLOW SCREEN OF DEATH".)

(Of course parsing is only a tiny part of the web platform, and probably one of the easiest parts for this kind of comprehensive specification and testing because it's a nice self-contained platform-independent linear transformation from bytes to a tree of elements (ignoring fiddly bits like document.write). But similar principles were applied with some success to other parts of the platform too, and I think the lesson is that it's a significant improvement over Postel's law.)