Changeset 1921

Timestamp:

01/10/12 04:39:53 (9 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:

• p2-semantics.html (modified) (4 diffs)
• p2-semantics.xml (modified) (3 diffs)

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

@@ -918 +918 @@
       <div id="rfc.iref.c.2"></div>
       <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>
-      <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,
-         the media type is that which would have been sent had the request been a GET.
+      <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
+         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
+         type is that which would have been sent had the request been a GET.
       </p>
       <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>
       <div id="rfc.figure.u.2"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
-</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>.
+</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,
+         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.
+      </p>
+      <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
+         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.
       </p>
       <div id="rfc.iref.c.3"></div>
@@ -1026 +1035 @@
       </p>
       <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
-</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
-         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
-         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 <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.
-      </p>
-      <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
-         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.
-      </p>
-      <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
-         are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
-         defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
-      </p>
-      <div id="rfc.iref.p.1"></div>
+</pre><div id="rfc.iref.p.1"></div>
       <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>
       <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>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li>
                   <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>
-                  <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>
-                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.2</a></li>
+                  <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>
+                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.1.1</a></li>
                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
                      </ul>

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>