- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 6 Jun 2009 20:10:16 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Adam Barth <w3c@adambarth.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 06/06/2009, at 7:58 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> Sounds like we're moving towards consensus (because no one is >> particularly happy). >> That would make the proposal to replace p3 3.2.1: >> ... >> with: >> """ >> When an entity-body is included with a message, the data type of that >> body is determined via the header fields Content-Type and Content- >> Encoding. These define a two-layer, ordered encoding model: >> entity-body := Content-Encoding( Content-Type( data ) ) >> Content-Type specifies the media type of the underlying data. Any >> HTTP/1.1 message containing an entity-body SHOULD include a >> Content-Type header field defining the media type of that body. If >> the Content-Type header field is not present, it indicates that the >> sender does not know the media type of the data; recipients MAY > > Q: maybe we should relax the "SHOULD" a bit more; I think it should > be totally clear that if a server doesn't know the type, and can't > guess it with some confidence, it SHOULD NOT include it. > > How about: > > "Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body, > unless that information is unknown." I read that as effectively equivalent to the current text, but sure; it is more explicit about when the SHOULD can be violated. >> either assume that it is "application/octet-stream" or examine the >> content to determine its type. >> Content-Encoding may be used to indicate any additional content >> codings applied to the data, usually for the purpose of data >> compression, that are a property of the requested resource. There is >> no default encoding. >> Note that neither the interpretation of the data type of a message >> nor >> the behaviours caused by it are not defined by HTTP; this >> potentially includes examination of the content to override any >> indicated type ("sniffing"). >> """ >> Question -- the wording above explicitly allows sniffing of both >> content-type and content-encoding; do we want to allow C-E? > > Does it? It's not obvious to me. If we don't want that (and I think > this is the case), we may want to swap the last two paragraphs. That's one solution, yes, but I'm not yet sure we have a problem. -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 6 June 2009 10:10:54 UTC