- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 06 Jun 2009 12:06:16 +0200
- To: Mark Nottingham <mnot@mnot.net>
- 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>
Mark Nottingham wrote: > Sounds like we're moving towards consensus (because no one is > particularly happy). > ... I have attached a proposed patch to ticket 155, containing Mark's proposal (plus the removal of the surplus "not", plus an explicit reference to the spec defining application/octet-stream): see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.diff>. The whole paragraph would then read: -- snip -- 3.2.1. Type 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 either assume that it is "application/octet-stream" ([RFC2046], Section 4.5.1) 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 behaviors caused by it are defined by HTTP; this potentially includes examination of the content to override any indicated type ("sniffing"). -- snip -- Note that this does NOT contain any changes related to the feedback I sent in my previous mail. BR, Julian (looking forward to get this issue from the table soon!)
Received on Saturday, 6 June 2009 10:07:03 UTC