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

Re: Content Sniffing impact on HTTPbis - #155

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 06 Jun 2009 11:58:27 +0200
Message-ID: <4A2A3DC3.4090706@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Adam Barth <w3c@adambarth.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> Sounds like we're moving towards consensus (because no one is 
> particularly happy).
> 
> That would make the proposal to replace p3 3.2.1:
> ...
> with:
> 
> """
> When an entity-body is included with a message, the data type of that
> body is determined via the header fields Content-Type and Content-
> Encoding.  These define a two-layer, ordered encoding model:
> 
>   entity-body := Content-Encoding( Content-Type( data ) )
> 
> Content-Type specifies the media type of the underlying data. Any
> HTTP/1.1 message containing an entity-body SHOULD include a
> Content-Type header field defining the media type of that body. If
> the Content-Type header field is not present, it indicates that the
> sender does not know the media type of the data; recipients MAY

Q: maybe we should relax the "SHOULD" a bit more; I think it should be 
totally clear that if a server doesn't know the type, and can't guess it 
with some confidence, it SHOULD NOT include it.

How about:

"Any HTTP/1.1 message containing an entity-body SHOULD include a 
Content-Type header field defining the media type of that body, unless 
that information is unknown."

> either assume that it is "application/octet-stream" or examine the
> content to determine its type.
> 
> Content-Encoding may be used to indicate any additional content
> codings applied to the data, usually for the purpose of data
> compression, that are a property of the requested resource.  There is
> no default encoding.
> 
> Note that neither the interpretation of the data type of a message nor
> the behaviours caused by it are not defined by HTTP; this
> potentially includes examination of the content to override any
> indicated type ("sniffing").
> """
> 
> Question -- the wording above explicitly allows sniffing of both 
> content-type and content-encoding; do we want to allow C-E?

Does it? It's not obvious to me. If we don't want that (and I think this 
is the case), we may want to swap the last two paragraphs.

> I'm not sure what "that are a property of the requested resource" means 
> in the context of content-encoding; it seems to be a variation of the 
> "requested variant" problem. Perhaps we can deal with that then...

BR, Julian
Received on Saturday, 6 June 2009 09:59:16 GMT

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