Ticket #155: i155.2.diff

p3-payload.xml

@@ -793 +793 @@
    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
+   unknown.
+</t>
+<t>   
+   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" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    or examine the content to determine its type.
 </t>
 <t>
+   In practice, currently-deployed servers sometimes 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.
+</t>
+<t>
+   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.
+</t>
+<t>
    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
@@ -3145 +3160 @@
       "IANA registry for content/transfer encodings"
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>:
+      "Content Sniffing"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
       "use of term "word" when talking about header structure"
     </t>