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: Fri, 5 Jun 2009 18:50:26 +1000
Cc: Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <EA18BA4D-3488-4917-9A93-F5B431794889@mnot.net>
To: Roy T. Fielding <fielding@gbiv.com>
Well, the reasoning behind saying something about application/octet- 
stream is that senders may rely on 2616's defaulting to that media  
type -- thereby preserving backwards-compatibility.

If we think that there's an interop problem here and it would serve  
better to not define a default, I'm fine with that.

It may be worth putting a note in to the effect that there used to be  
a default, though.

On 05/06/2009, at 6:29 PM, Roy T. Fielding wrote:

> On Jun 4, 2009, at 8:01 AM, 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").
>> """
> I think that conflicts with my analysis in the mime-respect TAG  
> finding.
> I would prefer that no Content-Type means that the server doesn't know
> the media type, thereby allowing the recipient to guess.
> ....Roy

Mark Nottingham     http://www.mnot.net/
Received on Friday, 5 June 2009 08:51:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC