Re: [whatwg/encoding] Amount of bytes to sniff for encoding detection (#102)

> Why would consistency with be `<meta>` be a goal here? I can't think of an argument for a concrete benefit of such consistency.

To rely on the Firefox experience that waiting for 1024 without a timeout doesn't break the Web. (I.e. there have been only a couple of complaints since Firefox 4 about scripts that intentionally send content piecemeal but unintentionally not having an early `meta` not having their initial output shown.)

Also, if the buffer size for byte pattern detection was greater than the buffer size for `meta` sniffing, there'd be a temptation to change `meta` sniffing to operate on the larger buffer, too, because that would then make perfect sense from a Chromium-only perspective, but then that would break the browser consensus for `meta`, and it would be hard to walk that back if Chromium later changed its mind and decided that byte pattern detection isn't as necessary after all as Chromium devs now suggest.

(On the topic of assessing necessity, it would be good to hear from Edge devs what exactly, if anything, they do about byte pattern sniffing considering that they don't have a manual override menu as a recourse, either.)

> I would much rather increase the constant than resort to this.

Increasing the constant makes the probability of breakage go up for pages that intentionally stall the TCP stream. Adding a timeout to address that concern has the problem of the relationship between the input bytes to DOM tree becoming timing-dependent.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/102#issuecomment-300095198

Received on Tuesday, 9 May 2017 08:21:03 UTC