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: Thu, 04 Jun 2009 22:41:59 +0200
Message-ID: <4A283197.6050007@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> Revised proposal:
> 
> Replace this text in p3 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. If the media type remains unknown, the recipient SHOULD 
>> treat it as type "application/octet-stream".
> with
> 
> """
> If the Content-Type field is not present in a message with a body, the 
> recipient SHOULD assume that the message was sent with a Content-Type of 
> "application/octet-stream".
> 
> Note that neither the interpretation of the data type of a message nor 
> the behaviours caused by it are not defined by this specification; this 
> potentially includes examination of the content to override the 
> indicated type ("sniffing").
> """
> ...

The second part sounds good.

The first part, now that sniffing isn't mentioned there anymore, makes 
"application/octet-stream" a default at SHOULD level.

The definition of "application/octet-stream" in 
<http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.5.1> has:

"The recommended action for an implementation that receives an 
"application/octet-stream" entity is to simply offer to put the data in 
a file, with any Content-Transfer-Encoding undone, or perhaps to use it 
as input to a user-specified process."

It's not really the intent to make *that* the default, right?

BR, Julian
Received on Thursday, 4 June 2009 20:42:43 GMT

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