- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 09 Apr 2009 14:46:13 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: Adam Barth <w3c@adambarth.com>, Mark Baker <mark@coactus.com>, =JeffH <Jeff.Hodges@kingsmountain.com>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > Works for me. > ... So 3.2.1 would become: -- snip -- 3.2.1 Type When an entity-body is included with a message, the data type of that body is declared by 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. 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. 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 media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream". -- snip -- Note that by removing the second sentence from the last paragraph, we now have a dangling "...if remains unknown...". So should this sentence go as well? (note that declaring application/octet-stream is really different from not declaring the type at all, IMHO). Furthermore, Mark N. wrote: > We'd still need security considerations text. So what would these be if we do not even mention sniffing? BR, Julian
Received on Thursday, 9 April 2009 12:47:02 UTC