Ignore:
Timestamp:
01/10/12 04:39:53 (8 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.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.