- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2009 16:00:48 +1000
- To: Mark Baker <mark@coactus.com>
- Cc: "=JeffH" <Jeff.Hodges@kingsmountain.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. Thoughts? On 08/04/2009, at 10:25 AM, Mark Baker wrote: > On Tue, Apr 7, 2009 at 6:11 PM, =JeffH > <Jeff.Hodges@kingsmountain.com> 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; > > http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0018.html > > Mark. > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 8 April 2009 06:01:30 UTC