- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 5 Jun 2009 18:50:26 +1000
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
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