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

Re: Content Sniffing impact on HTTPbis - #155

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 6 Jun 2009 20:10:16 +1000
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>
Message-Id: <5C9932D9-83ED-494E-8A4A-9D2E55C81CDC@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 06/06/2009, at 7:58 PM, Julian Reschke wrote:

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

I read that as effectively equivalent to the current text, but sure;  
it is more explicit about when the SHOULD can be violated.


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

That's one solution, yes, but I'm not yet sure we have a problem.


--
Mark Nottingham     http://www.mnot.net/
Received on Saturday, 6 June 2009 10:10:54 GMT

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