Changeset 831 for draft-ietf-httpbis

Timestamp:

29/06/10 17:11:54 (11 years ago)

Author:

julian.reschke@…

Message:

Say a bit more about the fact that some clients do sniff, and why this can be very dangerous (see #155)

Location:

draft-ietf-httpbis/latest

Files:

• p3-payload.html (modified) (6 diffs)
• p3-payload.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p3-payload.html

@@ -401 +401 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-06-02">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-06-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
@@ -427 +427 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 4, 2010</td>
+               <td class="left">Expires: December 31, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -484 +484 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 2, 2010</td>
+               <td class="right">June 29, 2010</td>
             </tr>
          </tbody>
@@ -510 +510 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in December 4, 2010.</p>
+      <p>This Internet-Draft will expire in December 31, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -908 +908 @@
       </p>
       <div id="rfc.figure.u.14"></div><pre class="text">  entity-body := Content-Encoding( Content-Type( data ) )
-</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> 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 <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
-      </p>
-      <p id="rfc.section.3.2.1.p.4">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data
+</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.
+      </p>
+      <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
+      </p>
+      <p id="rfc.section.3.2.1.p.5">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.
+      </p>
+      <p id="rfc.section.3.2.1.p.6">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.
+      </p>
+      <p id="rfc.section.3.2.1.p.7">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.
       </p>
@@ -2050 +2058 @@
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>&gt;: "IANA registry for content/transfer encodings"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"

draft-ietf-httpbis/latest/p3-payload.xml

@@ -794 +794 @@
    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>
@@ -3146 +3161 @@
     </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"