Re: NEW ISSUE: content sniffing

 > Ian Hickson <ian@hixie.ch> wrote:
 >
 > We're not saying HTTP should care about them. We're saying that one of
 > these two options should be picked:
 >
 > Either:
 >
 > a) HTTP should not have any requirements for how to process Content-Type
 > headers, and should just leave Content-Type to another spec, or:
 >
 > b) HTTP should include the proposed limited Content-Sniffing algorithm,
 > which would allow us to get software tools to converge on a single set of
 > heuristics and thus reduce the security risk.


upon reflection WRT the above, I would pick option (a) -- i.e. RFC2616 (s7.2.1) 
arguably says "too much" concerning the Content-Type header field. My 
overriding rationale being that there is a (growing) plethora of "protocols" 
layered upon HTTP, and RFC2616 was written back when a "web browser cum user" 
(my poor phrase) was arguably dominant.

Here's the relevant last para of section 7.2.1..

     7.2.1 Type

     <snip/>

     Any HTTP/1.1 message containing an entity-body SHOULD include a
     Content-Type header field defining the media type of that body. 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".

Specifically, I'm thinking that the last paragraph really should read
something more like..

     Any HTTP/1.1 message containing an entity-body SHOULD include a
     Content-Type header field defining the media type of that body.
     Processing of the entity-body SHOULD be based on the Content-Type
     header field value and MAY be based as well on other header field
     values.  Definition of such further processing is out-of-scope of
     this specification. If the media type is not given by a
     Content-Type header field the recipient's behavior is not defined
     by this specification.

..though I'm not very sure about the last sentence (wrt absence of
Content-Type header field).

Might this -- i.e. the last para of RFC2616 s7.2.1 presently saying "too much" 
-- be viewed as a "bug" in RFC2616?


Overall this thread of course begs the question of where/how to publish 
draft-abarth-mime-sniff and/or other specs defining behavior(s) of (certain 
classes of) HTTP-based apps and their implementations. E.g. how do we signal to 
browser vendors et al the set of HTTP-oriented specs (for example) they ought 
to adhere to (this question of course applies to the specs of a wide array of 
protocols and formats).

thanks,

=JeffH

Received on Tuesday, 7 April 2009 22:13:53 UTC