Changeset 1921 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 01/10/12 04:39:53 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1920 r1921 918 918 <div id="rfc.iref.c.2"></div> 919 919 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h3> 920 <p id="rfc.section.3.1.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 921 the media type is that which would have been sent had the request been a GET. 920 <p id="rfc.section.3.1.1.p.1">The "Content-Type" header field indicates the media type of the representation, which defines both the data format and how 921 that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). For responses to the HEAD method, the media 922 type is that which would have been sent had the request been a GET. 922 923 </p> 923 924 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> … … 925 926 </p> 926 927 <div id="rfc.figure.u.2"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 927 </pre><p id="rfc.section.3.1.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 3.2</a>. 928 </pre><p id="rfc.section.3.1.1.p.5">A sender <em class="bcp14">SHOULD</em> include a Content-Type header field in a message containing a payload body, defining the media type of the enclosed representation, 929 unless the intended media type is unknown to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><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 representation data to determine its type. 930 </p> 931 <p id="rfc.section.3.1.1.p.6">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for 932 a given representation, with the result that some clients will examine a payload's content and override the specified type. 933 Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). 934 Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple 935 media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content 936 sniffing" when it is used. 928 937 </p> 929 938 <div id="rfc.iref.c.3"></div> … … 1026 1035 </p> 1027 1036 <div id="rfc.figure.u.9"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 1028 </pre><p id="rfc.section.3.2.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 1029 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown 1030 to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type 1031 of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><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. 1032 </p> 1033 <p id="rfc.section.3.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for 1034 a given representation, with the result that some clients will examine a payload's content and override the specified type. 1035 Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). 1036 Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple 1037 media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content 1038 sniffing" when it is used. 1039 </p> 1040 <p id="rfc.section.3.2.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that 1041 are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that 1042 defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. 1043 </p> 1044 <div id="rfc.iref.p.1"></div> 1037 </pre><div id="rfc.iref.p.1"></div> 1045 1038 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="payload" href="#payload">Message Payload</a></h2> 1046 1039 <p id="rfc.section.3.3.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or … … 5209 5202 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li> 5210 5203 <li><em>RFC2045</em> <a href="#RFC2045"><b>12.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li> 5211 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">3. 2</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>5212 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.1">3. 2</a></li>5204 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">3.1.1</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul> 5205 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.1">3.1.1</a></li> 5213 5206 <li><em>Section 5.1.1</em> <a href="#rfc.xref.RFC2046.3">8.5.2</a></li> 5214 5207 </ul>
Note: See TracChangeset
for help on using the changeset viewer.