- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 15 Jun 2010 01:47:27 +0000
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, HTTP Working Group <ietf-http-wg@w3.org>
- Cc: "public-html@w3.org WG" <public-html@w3.org>, TAG List <www-tag@w3.org>
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? Regards, On 10/06/2010, at 9:52 AM, Mark Nottingham wrote: > Henry, > > My only concern with [2] is this set of requirements > >> Such recipients SHOULD NOT override the specified type it there are >> known security risks and they SHOULD provide for users to disable such >> heuristic Content-Type detection. > > as discussed before. > > HTTPbis can introduce new requirements that break existing implementations only where there are overriding security and/or interoperability concerns. > > While it could be argued that this holds true here, the first requirement is quite vague, and the second will AFAIK make every existing implementation non-conformant (with the possibility that they will remain so indefinitely). > > Would the TAG be amenable to either dropping this sentence from the proposal, or modifying the text at [3] to address your concerns? > > Regards, > > > On 09/06/2010, at 10:47 PM, Henry S. Thompson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Further to the TAG's suggestion in [1] regarding 'sniffing', and >> replies from Yves Lafon [2] and Mark Nottingham [3], the TAG has asked >> me to convey our thanks for your willingness to reopen this issue. >> With some minor adjustments, we are happy that the text proposed at [2] >> addresses most of our concerns. >> >> We suggest the following two minor changes: >> >> does not correctly identify the content sent >> >> --> >> >> does not reflect the intended interpretation of the content sent >> >> and >> >> Such recipients SHOULD NOT >> >> --> >> >> Recipients SHOULD NOT >> >> We would however prefer that something about this issue also remain in >> section 3.1.2. Perhaps keep >> >> If the Content-Type header field is present, a recipient which >> interprets the underlying data in a way inconsistent with the >> specified media type risks drawing incorrect conclusions. >> >> in 3.1.2, adding something along the lines of "See [7.3] for a related >> security issue.", but we are happy to leave this to your editorial >> discretion. >> >> We are less happy with the proposed addition suggested by Mark in [3], >> on the grounds that it a) implies that documents have media types in >> some intrinsic way, which we think is at best misleading, and that b) >> the straw men it sets up will in fact be counterproductive. >> >> ht, on behalf of the TAG >> >> [1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0493.html >> [2] http://lists.w3.org/Archives/Public/public-html/2010Mar/0659.html >> [3] http://lists.w3.org/Archives/Public/public-html/2010May/0330.html >> [This message pertains to TAG ACTION-370] >> - -- >> Henry S. Thompson, School of Informatics, University of Edinburgh >> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 >> Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk >> URL: http://www.ltg.ed.ac.uk/~ht/ >> [mail from me _always_ has a .sig like this -- mail without it is forged spam] >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.6 (GNU/Linux) >> >> iD8DBQFMD414kjnJixAXWBoRAr4EAJ9W4zFN1SywFjfMG8QQtXAiPPmaIwCfbAw2 >> rZ/VkbMn24RAI2S6OoMUDWU= >> =dhkn >> -----END PGP SIGNATURE----- > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 15 June 2010 02:03:05 UTC