- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 04 Jun 2009 22:41:59 +0200
- 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 UTC