Ignore:
Timestamp:
Sep 30, 2012, 9:39:53 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) move content-type discussion to content-type section; remove duplicate content-encoding definition

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1920 r1921  
    918918      <div id="rfc.iref.c.2"></div>
    919919      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<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.
    922923      </p>
    923924      <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>
     
    925926      </p>
    926927      <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&nbsp;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.
    928937      </p>
    929938      <div id="rfc.iref.c.3"></div>
     
    10261035      </p>
    10271036      <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>
    10451038      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
    10461039      <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
     
    52095202                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    52105203                  <li><em>RFC2045</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.2</a></li>
     5204                  <li><em>RFC2046</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.1.1</a></li>
    52135206                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
    52145207                     </ul>
Note: See TracChangeset for help on using the changeset viewer.