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

Re: NEW ISSUE: content sniffing

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 31 Mar 2009 08:35:40 -0700
Message-ID: <7789133a0903310835y1d8a199bke137a627b03b8f30@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
If you'd like to learn more about the security and compatibility
considerations that lead to draft-abarth-mime-sniff, you might enjoy
reading:

http://www.adambarth.com/papers/2009/barth-caballero-song.pdf

Let me know how I can be of assistance on this issue.

Adam


On Mon, Mar 30, 2009 at 4: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.
>
> The language should be updated to reflect this reality, without unduly
> encouraging the use of sniffing except where necessary. Ideally, it will be
> done in such a way that:
>
>  * Does not require sniffing for all uses of HTTP (i.e., a particular
> implementation and/or user can "opt in" to the use of a sniffing algorithm),
> since this is most commonly a problem for the browser case, and
>  * Specifically allows a user and/or content provider to opt out of the use
> of sniffing in a particular interaction, and
>  * Promotes interoperability (i.e., if two implementations sniff, they will
> do so in the same way).
>
> See:
>  http://tools.ietf.org/html/draft-abarth-mime-sniff
> for a proposal sourced from HTML5.
>
> Besides the issue of sniffing itself, there's also an open question of
> whether the sniffing algorithm would remain in a separate document (i.e.,
> our work would only be to relax requirements to allow it), or whether it
> would be in-document.
>
> In either case, we'd have to take a serious look at security considerations,
> and also look at impact on intermediaries, etc.
>
> Note that this is not about sniffing encoding directly (see issue #20),
> although the resolution may be related.
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>
Received on Tuesday, 31 March 2009 15:36:31 GMT

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