Changeset 831 for draft-ietf-httpbis
- Timestamp:
- 29/06/10 17:11:54 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p3-payload.html
r824 r831 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <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"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: December 4, 2010</td>429 <td class="left">Expires: December 31, 2010</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">June 2 , 2010</td>486 <td class="right">June 29, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </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> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 908 908 </p> 909 909 <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 914 922 compression, that are a property of the requested resource. There is no default encoding. 915 923 </p> … … 2050 2058 <ul> 2051 2059 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>>: "IANA registry for content/transfer encodings" 2060 </li> 2061 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>>: "Content Sniffing" 2052 2062 </li> 2053 2063 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>>: "use of term "word" when talking about header structure" -
draft-ietf-httpbis/latest/p3-payload.xml
r824 r831 794 794 message containing an entity-body &SHOULD; include a Content-Type header 795 795 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 797 800 the sender does not know the media type of the data; recipients &MAY; 798 801 either assume that it is "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 799 802 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. 800 815 </t> 801 816 <t> … … 3146 3161 </t> 3147 3162 <t> 3163 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>: 3164 "Content Sniffing" 3165 </t> 3166 <t> 3148 3167 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: 3149 3168 "use of term "word" when talking about header structure"
Note: See TracChangeset
for help on using the changeset viewer.