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

Re: NEW ISSUE: content sniffing

From: Mark Baker <mark@coactus.com>
Date: Tue, 31 Mar 2009 14:13:47 +0000
Message-ID: <e9dffd640903310713s47afe255ubb7f1571d911810@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Mar 30, 2009 at 7:58 PM, Mark Nottingham <mnot@mnot.net> wrote:
> [ As discussed in SF ]
>
> Browsers now routinely 'sniff' content to determine its type, sometimes in
> conflict with the media type conveyed in the Content-Type header. The
> reasons most often cited for this practice are the misconfiguration of
> servers, the inability of content authors to configure servers (either for
> technical reasons or lack of education), and generally the incentives placed
> upon browser vendors to "just work."
>
> p3-payload section 3.2.1. currently says:
>>
>> If and only if the media type is not given by a Content-Type field, the
>> recipient MAY attempt to guess the media type via inspection of its content
>> and/or the name extension(s) of the URI used to identify the resource. If
>> the media type remains unknown, the recipient SHOULD treat it as type
>> "application/octet-stream".
>
> which effectively disallows this practice, despite widespread use that
> (apparently) isn't stopping any time soon.

That paragraph doesn't seem to me to apply to the typical sniffing
scenario discussed by draft-abarth-mime-sniff, as it deals only with
unspecified media types rather than their intentional overriding.

Obviously that kind of sniffing is widespread amoungst one class of
agent, and I'm all for documenting how it works, but IMO that has no
place in the protocol specification, save perhaps for an informative
note that it happens and a pointer to the algorithm.

Mark.
Received on Tuesday, 31 March 2009 18:16:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT