W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: NEW ISSUE: content sniffing

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 1 Apr 2009 09:01:39 -0700
Message-ID: <7789133a0904010901t411fa57fm51e4019cdce733d2@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
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).

Adam
Received 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