Changeset 831


Ignore:
Timestamp:
Jun 29, 2010, 10:11:54 AM (9 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:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r824 r831  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-06-02">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-06-29">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <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.">
     
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: December 4, 2010</td>
     429               <td class="left">Expires: December 31, 2010</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
     
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">June 2, 2010</td>
     486               <td class="right">June 29, 2010</td>
    487487            </tr>
    488488         </tbody>
     
    510510         in progress”.
    511511      </p>
    512       <p>This Internet-Draft will expire in December 4, 2010.</p>
     512      <p>This Internet-Draft will expire in December 31, 2010.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    908908      </p>
    909909      <div id="rfc.figure.u.14"></div><pre class="text">  entity-body := Content-Encoding( Content-Type( data ) )
    910 </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
    911          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.
    912       </p>
    913       <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
     910</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.
     911      </p>
     912      <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.
     913      </p>
     914      <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
     915         interpretation of the content sent, with the result that some clients will examine the response body's content and override
     916         the specified type.
     917      </p>
     918      <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").
     919         Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
     920      </p>
     921      <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
    914922         compression, that are a property of the requested resource. There is no default encoding.
    915923      </p>
     
    20502058      <ul>
    20512059         <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"
     2060         </li>
     2061         <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"
    20522062         </li>
    20532063         <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

    r824 r831  
    794794   message containing an entity-body &SHOULD; include a Content-Type header
    795795   field defining the media type of that body, unless that information is
    796    unknown.  If the Content-Type header field is not present, it indicates that
     796   unknown.
     797</t>
     798<t>   
     799   If the Content-Type header field is not present, it indicates that
    797800   the sender does not know the media type of the data; recipients &MAY;
    798801   either assume that it is "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    799802   or examine the content to determine its type.
     803</t>
     804<t>
     805   In practice, currently-deployed servers sometimes provide a Content-Type
     806   header which does not correctly convey the intended interpretation of the
     807   content sent, with the result that some clients will examine the response
     808   body's content and override the specified type.
     809</t>
     810<t>
     811   Client that do so risk drawing incorrect conclusions, which may expose
     812   additional security risks (e.g., "privilege escalation"). Implementers are
     813   encouraged to provide a means of disabling such "content sniffing" when it
     814   is used.
    800815</t>
    801816<t>
     
    31463161    </t>
    31473162    <t>
     3163      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>:
     3164      "Content Sniffing"
     3165    </t>
     3166    <t>
    31483167      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
    31493168      "use of term "word" when talking about header structure"
Note: See TracChangeset for help on using the changeset viewer.