Re: NEW ISSUE: content sniffing

some servers sent certain mime types as a default if the actual mime 
type was unknown or there was no mapping for the file extension.

I don't know how common this is any more, but it certainly created a 
need for sniffing, since the "authoritative" mime type was a bad guess.

In fact the concept of what constitutes an authoritative mime type is a 
bit tenuous.  if it's a web server guess, then what makes it any better 
than a client's guess.  frequently it will be worse.

maybe we need a weakness indicator for the content type field, e.g

Content-Type: W/"application/octet-stream"


Content-Type: application/octet-stream ; certainty = random-guess

meaning "we think it might be application/octet-stream"

IOW, maybe an indication of whether to sniff or not shouldn't be another 
header, but a parameter of the Content-Type header.

Then one could indicate the source/strength of the mime type, e.g.

* explicitly set by management interface
* explicitly set by CGI / script
* guessed by file extension
* guessed by sniffing at server
* guessed by sniffing at intermediary
* pulled out of a hat


Adam Barth wrote:
> On Wed, Apr 1, 2009 at 9:10 AM, Mark Baker <> wrote:
>> On Wed, Apr 1, 2009 at 12:01 PM, Adam Barth <> wrote:
>>> 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).
>> Which requirement is that?
> >From
> "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."
> For example, user agents also need to sniff HTTP responses with a
> Content-Type of */* in order to be compatible with existing Web
> content.
> Adam

Adrien de Croy - WinGate Proxy Server -

Received on Wednesday, 1 April 2009 21:17:34 UTC