On Wed, Apr 1, 2009 at 1:46 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Adam Barth wrote: >> Regardless, many popular user agents override the server-provided MIME >> type after examining the content of HTTP responses. > > But only for a certain set of MIME types, which are known to be frequently > incorrect, right? Yes. It appears to be sufficiently compatible to limit sniffing to a handful of MIME types. These are listed in draft-abarth-mime-sniff. >> Content sniffing algorithms in browsers largely ignore the context in >> which the HTTP response is being used. Specifically, algorithm for >> computing the effective MIME type is a function of the HTTP response >> alone (both in practice and in draft-abarth-mime-sniff). > > My understanding was that the context *is* relevant (stylesheet? image?). In browsers, there are two contexts that do not use the context-independent sniffer: 1) The <script> tag largely ignores MIME types. I don't really think of this as MIME sniffing. It's more that the <script> tag doesn't care about MIME types. 2) A style sheet loaded via <link rel="stylesheet" href="..."> in quirks mode also ignores MIME types. In standards mode, however, this context uses the same context-independent MIME sniffer as everything else. Historically, the <img> tag did have a more aggressive image-specific sniffer, but this does not appear to be required for Web compatibility and has been removed in major implementations. > As long as it is clear that it's still an option not to sniff at all, and as > long as the goal remains to minimize the amount of sniffing going on... Yes. I believe we are in agreement on these points. > That said, why is it important that the HTTP spec references this document? The current HTTP spec contains a requirement that contradicts this widespread practice. It seems we should update this part of the spec to reflect reality (and, perhaps, nudge reality into a slightly better equilibrium). AdamReceived on Wednesday, 1 April 2009 16:02:32 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC