PROPOSAL: content sniffing [#155]

It seems like Mark's proposal is the minimum required to declare  
victory, from an HTTP standpoint at least.

Remove this text from p3 section 3.2.1:
> "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."
We'd still need security considerations text.

Regarding a mechanism to opt in or out of sniffing -- while this is a  
necessary discussion, it would be a new mechanism, as well as new  
conformance requirement (almost certainly making existing  
implementations non-conformant), so it's out of scope for us. That  
said, drafts can still be reviewed on-list, it just isn't a WG product.


On 08/04/2009, at 10:25 AM, Mark Baker wrote:

> On Tue, Apr 7, 2009 at 6:11 PM, =JeffH  
> <> wrote:
>> 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.
> That text isn't specifying a protocol, it's specifying how
> implementations should behave.  We need the protocol specification to
> specify what messages *mean* when the Content-Type header is there and
> when it isn't, and we already have that text.
> My previous suggestion is as far as I would feel comfortable going
> along these lines;
> Mark.

Mark Nottingham

Received on Wednesday, 8 April 2009 06:01:30 UTC