Re: content sniffing (and HTTP profiling)

Personally, I can get on board with this approach.

The only thing that I think may need to be added (and I think this was  
discussed in SF) is advice on allowing origins and users the ability  
to opt out of sniffing on a per-response basis. Putting that advice in  
HTTPbis is probably best, although I could see arguments for putting  
it in the sniffing algorithm.

WRT defining the 'stack' of specs that a browser should adhere to --  
this has come up in side conversations, but never addressed fully. I  
know Lisa is quite interested in defining "profiles" for use of HTTP,  
so that other IETF specs can specify them and not have to worry about  
all of the details of what should or should not be done.

Likewise, a profile for browsers sounds like it would be useful.

If HTTPbis does its job well, the new HTTP specs should be much more  
suitable for profiling than 2616, both because of the explicit split  
into many components, and because we're chartered to more carefully  
define extensibility.

I can see this group starting to work on a HTTP profile for IETF specs  
at some point (arguably soon, if there's interest, so that we can get  
feedback from building the profile into HTTPbis). I'm not as sure that  
doing a browser profile in this group makes as much since, because the  
profile they're interested  in has a lot of other technologies in it  
as well...

AIUI HTML5 was originally that profile, but since recently it's been  
fragmenting into multiple specs, it may be that a separate browser  
profile is needed. CC'ing Sam and Chris to get their thoughts on  
whether this is something they'd like to take on, and what level of  
liaison might be necessary.



On 08/04/2009, at 8:11 AM, =JeffH wrote:

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


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 7 April 2009 23:24:23 UTC