Re: Content Sniffing impact on HTTPbis - #155

Wors for me, although I don't know that the last sentence is really  
necessary. Are you explicitly removing application/octet-stream as a  
default if no other type is found or derived?


On 02/06/2009, at 10:00 PM, Bjoern Hoehrmann wrote:

> * Mark Nottingham wrote:
>> Are you referring to this:
>>> The entity-header field "Content-Type" indicates the media type of
>>> the entity-body sent to the recipient or, in the case of the HEAD
>>> method, the media type that would have been sent had the request
>>> been a GET.
>> in p3 5.9?
>> If so, I think you're reading too much into 'indicates', and IIRC  
>> this
>> discussion has been had on list before. The question is not what
>> defines the media type, it's what an application can or cannot do  
>> with
>> that information once the indication is available.
> I believe RFC 2616 uses the word "indicate" to mean "define",  
> "specify";
> the part you quoted for example is immediately preceded by "an entity-
> body SHOULD include a Content-Type header field defining the media  
> type
> of that body." That would not be possible if the Content-Type  
> header, if
> present, did not define the media type.
> It seems to me that all the original text said is that the HTTP layer
> must report the media type as specified in the Content-Type header to
> the next layer. What that layer does with the information is out of
> scope of the HTTP specification. In that I agree with you on what the
> issue really is.
> A viable alternative to your proposals might, then, be to replace the
> whole paragraph in question by (removing any "sniffing" discussion):
>   Any HTTP/1.1 message containing an entity-body SHOULD include a
>   Content-Type header field defining the media type of that body.
>   How the media type of the entity-body affects the behavior of
>   higher-level applications is out of scope of this specification.
> -- 
> Björn Höhrmann · ·
> Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http:// 

Mark Nottingham

Received on Wednesday, 3 June 2009 01:31:49 UTC