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

Timestamp:

01/10/12 04:39:53 (10 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.html (modified) (4 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>