Changeset 1921 for draft-ietf-httpbis/latest/p2-semantics.xml

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:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -318 +318 @@
 <t>
    The "Content-Type" header field indicates the media type of the
-   representation. In the case of responses to the HEAD method, the media type is
+   representation, which defines both the data format and how that data
+   &SHOULD; be processed by the recipient (within the scope of the request
+   method semantics). For responses to the HEAD method, the media type is
    that which would have been sent had the request been a GET.
 </t>
@@ -331 +333 @@
 </artwork></figure>
 <t>
-   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
+   A sender &SHOULD; include a Content-Type header field in a message
+   containing a payload body, defining the media type of the enclosed
+   representation, unless the intended media type is unknown to the sender.
+   If a Content-Type header field is not present, recipients &MAY; either
+   assume a media type of
+   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
+   or examine the representation data to determine its type.
+</t>
+<t>
+   In practice, resource owners do not always properly configure their origin
+   server to provide the correct Content-Type for a given representation,
+   with the result that some clients will examine a payload's content
+   and override the specified type.
+   Clients that do so risk drawing incorrect conclusions, which might expose
+   additional security risks (e.g., "privilege escalation").  Furthermore,
+   it is impossible to determine the sender's intent by examining the data
+   format: many data formats match multiple media types that differ only in
+   processing semantics.  Implementers are encouraged to provide a means of
+   disabling such "content sniffing" when it is used.
 </t>
 </section>
@@ -546 +566 @@
   representation-data := Content-Encoding( Content-Type( bits ) )
 </artwork></figure>
-<t>
-   <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
-   which defines both the data format and how that data &SHOULD; be processed
-   by the recipient (within the scope of the request method semantics).
-   Any HTTP/1.1 message containing a payload body &SHOULD; include a
-   Content-Type header field defining the media type of the associated
-   representation unless that metadata is unknown to the sender.
-   If the Content-Type header field is not present, it indicates that
-   the sender does not know the media type of the representation;
-   recipients &MAY; either assume that the media type is
-   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
-   or examine the content to determine its type.
-</t>
-<t>
-   In practice, resource owners do not always properly configure their origin
-   server to provide the correct Content-Type for a given representation,
-   with the result that some clients will examine a payload's content
-   and override the specified type.
-   Clients that do so risk drawing incorrect conclusions, which might expose
-   additional security risks (e.g., "privilege escalation").  Furthermore,
-   it is impossible to determine the sender's intent by examining the data
-   format: many data formats match multiple media types that differ only in
-   processing semantics.  Implementers are encouraged to provide a means of
-   disabling such "content sniffing" when it is used.
-</t>
-<t>
-   <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
-   codings applied to the data, usually for the purpose of data
-   compression, that are a property of the representation.  If
-   Content-Encoding is not present, then there is no additional
-   encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
-</t>
 </section>