- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Jun 2010 13:20:04 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, HTTP Working Group <ietf-http-wg@w3.org>, "public-html@w3.org WG" <public-html@w3.org>, TAG List <www-tag@w3.org>
On 15.06.2010 03:46, Mark Nottingham wrote: > The HTTPbis editors discussed this yesterday, and came up with the following proposal: > > ---8<--- > 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. > > In practice, currently-deployed servers sometime provide a Content-Type header which does not correctly convey the intended interpretation of the content sent, with the result that some clients will examine the response body's content and override the specified type. > > Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation"). Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used. > > 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. > --->8--- > > New text is the two paragraphs starting with "In practice..." > > Thoughts, both from the HTTPbis WG, the HTML WG and the TAG? > ... I think this is good, because...: - it accurately reflects the situation - it doesn't make new normative requirements we know won't be adhered to - it points out the risks, without going into too much detail (which would require lots of additional work that really needs to go somewhere else) Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/i155.diff> Best regards, Julian
Received on Tuesday, 15 June 2010 11:20:46 UTC