* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 831


Ignore:
Timestamp:
2010-06-29 10:11:54 (4 years ago)
Author:
julian.reschke@gmx.de
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.