Changeset 1921


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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1920 r1921  
    318318<t>
    319319   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
    321323   that which would have been sent had the request been a GET.
    322324</t>
     
    331333</artwork></figure>
    332334<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.
    334354</t>
    335355</section>
     
    546566  representation-data := Content-Encoding( Content-Type( bits ) )
    547567</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 processed
    551    by the recipient (within the scope of the request method semantics).
    552    Any HTTP/1.1 message containing a payload body &SHOULD; include a
    553    Content-Type header field defining the media type of the associated
    554    representation unless that metadata is unknown to the sender.
    555    If the Content-Type header field is not present, it indicates that
    556    the sender does not know the media type of the representation;
    557    recipients &MAY; either assume that the media type is
    558    "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 origin
    563    server to provide the correct Content-Type for a given representation,
    564    with the result that some clients will examine a payload's content
    565    and override the specified type.
    566    Clients that do so risk drawing incorrect conclusions, which might expose
    567    additional security risks (e.g., "privilege escalation").  Furthermore,
    568    it is impossible to determine the sender's intent by examining the data
    569    format: many data formats match multiple media types that differ only in
    570    processing semantics.  Implementers are encouraged to provide a means of
    571    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 content
    575    codings applied to the data, usually for the purpose of data
    576    compression, that are a property of the representation.  If
    577    Content-Encoding is not present, then there is no additional
    578    encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
    579 </t>
    580568</section>
    581569
Note: See TracChangeset for help on using the changeset viewer.