- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 07 Jun 2009 16:01:06 +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:
> OK. Please regenerate the diff with this change. It doesn't sound like
> people feel we need to close off the possibility of sniffing encoding,
> so I think the rest can stay the same...
> ...
OK, new proposed patch:
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.2.diff>
Full text of 3.2.1:
--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, unless that
information is unknown. 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 --
Best regards, Julian
Received on Sunday, 7 June 2009 14:01:50 UTC