Changeset 1921
- Timestamp:
- 01/10/12 04:39:53 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 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> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1920 r1921 318 318 <t> 319 319 The "Content-Type" header field indicates the media type of the 320 representation. In the case of responses to the HEAD method, the media type is 320 representation, which defines both the data format and how that data 321 &SHOULD; be processed by the recipient (within the scope of the request 322 method semantics). For responses to the HEAD method, the media type is 321 323 that which would have been sent had the request been a GET. 322 324 </t> … … 331 333 </artwork></figure> 332 334 <t> 333 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 335 A sender &SHOULD; include a Content-Type header field in a message 336 containing a payload body, defining the media type of the enclosed 337 representation, unless the intended media type is unknown to the sender. 338 If a Content-Type header field is not present, recipients &MAY; either 339 assume a media type of 340 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 341 or examine the representation data to determine its type. 342 </t> 343 <t> 344 In practice, resource owners do not always properly configure their origin 345 server to provide the correct Content-Type for a given representation, 346 with the result that some clients will examine a payload's content 347 and override the specified type. 348 Clients that do so risk drawing incorrect conclusions, which might expose 349 additional security risks (e.g., "privilege escalation"). Furthermore, 350 it is impossible to determine the sender's intent by examining the data 351 format: many data formats match multiple media types that differ only in 352 processing semantics. Implementers are encouraged to provide a means of 353 disabling such "content sniffing" when it is used. 334 354 </t> 335 355 </section> … … 546 566 representation-data := Content-Encoding( Content-Type( bits ) ) 547 567 </artwork></figure> 548 <t>549 <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,550 which defines both the data format and how that data &SHOULD; be processed551 by the recipient (within the scope of the request method semantics).552 Any HTTP/1.1 message containing a payload body &SHOULD; include a553 Content-Type header field defining the media type of the associated554 representation unless that metadata is unknown to the sender.555 If the Content-Type header field is not present, it indicates that556 the sender does not know the media type of the representation;557 recipients &MAY; either assume that the media type is558 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)559 or examine the content to determine its type.560 </t>561 <t>562 In practice, resource owners do not always properly configure their origin563 server to provide the correct Content-Type for a given representation,564 with the result that some clients will examine a payload's content565 and override the specified type.566 Clients that do so risk drawing incorrect conclusions, which might expose567 additional security risks (e.g., "privilege escalation"). Furthermore,568 it is impossible to determine the sender's intent by examining the data569 format: many data formats match multiple media types that differ only in570 processing semantics. Implementers are encouraged to provide a means of571 disabling such "content sniffing" when it is used.572 </t>573 <t>574 <x:ref>Content-Encoding</x:ref> is used to indicate any additional content575 codings applied to the data, usually for the purpose of data576 compression, that are a property of the representation. If577 Content-Encoding is not present, then there is no additional578 encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.579 </t>580 568 </section> 581 569
Note: See TracChangeset
for help on using the changeset viewer.