Changeset 875 for draft-ietf-httpbis/latest/p3-payload.html

Timestamp:

23/07/10 05:43:59 (12 years ago)

Author:

fielding@…

Message:

regenerate html

File:

• draft-ietf-httpbis/latest/p3-payload.html (modified) (41 diffs)

draft-ietf-httpbis/latest/p3-payload.html

@@ -377 +377 @@
       <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
       <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2">
-      <link rel="Chapter" title="3 Entity" href="#rfc.section.3">
+      <link rel="Chapter" title="3 Representation" href="#rfc.section.3">
       <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4">
       <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
@@ -384 +384 @@
       <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
       <link rel="Chapter" href="#rfc.section.9" title="9 References">
-      <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A">
+      <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
       <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
       <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C">
@@ -555 +555 @@
             </ul>
          </li>
-         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#entity">Entity</a><ul class="toc">
+         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
                <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#entity.header.fields">Entity Header Fields</a></li>
-               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#entity.body">Entity Body</a><ul class="toc">
+               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a><ul class="toc">
                      <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
                   </ul>
@@ -597 +597 @@
          </li>
          <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
-         <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc">
+         <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul class="toc">
                <li class="tocline1">A.1&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li>
                <li class="tocline1">A.2&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
@@ -818 +818 @@
       </p>
       <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>
-      <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next
-         paragraph.
+      <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
       </p>
       <p id="rfc.section.2.3.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and
          allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
-         entire entity-body. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if
-         the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for
-         some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent
-         the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body;
-         a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
-      </p>
-      <p id="rfc.section.2.3.1.p.3">If an entity-body is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
-      </p>
-      <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character set (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
-         to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or
-         its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section&nbsp;2.1.1</a> for compatibility problems.
+         entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is
+         in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte
+         character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the
+         equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload
+         body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
+      </p>
+      <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
+      </p>
+      <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
+         to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1"
+         or its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section&nbsp;2.1.1</a> for compatibility problems.
       </p>
       <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
-      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All
-         multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
+      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message-body.
+         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
       </p>
       <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does
@@ -866 +865 @@
 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
       </p>
-      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="entity" href="#entity">Entity</a></h1>
+      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
       <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
          of entity-header fields and a representation body, although some responses will only include the entity-headers.
@@ -874 +873 @@
       </p>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>
-      <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the entity-body or, if no body is present, about the resource identified by the
-         request.
+      <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is
+         present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the
+         Effective Request URI.
       </p>
       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#entity.header.fields" class="smpl">entity-header</a>  = <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
@@ -892 +892 @@
          fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies.
       </p>
-      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="entity.body" href="#entity.body">Entity Body</a></h2>
-      <p id="rfc.section.3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
-      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#entity.body" class="smpl">entity-body</a>    = *<a href="#notation" class="smpl">OCTET</a>
-</pre><p id="rfc.section.3.2.p.3">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
+      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
+      <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
+      <p id="rfc.section.3.2.p.2">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
          safe and proper transfer of the message.
       </p>
       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="type" href="#type">Type</a></h3>
-      <p id="rfc.section.3.2.1.p.1">When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type
+      <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type
          and Content-Encoding. These define a two-layer, ordered encoding model:
       </p>
-      <div id="rfc.figure.u.14"></div><pre class="text">  entity-body := Content-Encoding( Content-Type( data ) )
-</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.
+      <div id="rfc.figure.u.13"></div><pre class="text">  payload-body := Content-Encoding( Content-Type( data ) )
+</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. 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 that body, unless that information is unknown.
       </p>
       <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><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.
@@ -911 +910 @@
          the specified type.
       </p>
-      <p id="rfc.section.3.2.1.p.6">Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").
+      <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").
          Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
       </p>
       <p id="rfc.section.3.2.1.p.7">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data
-         compression, that are a property of the requested resource. There is no default encoding.
+         compression, that are a property of the representation. There is no default encoding.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
@@ -977 +976 @@
       <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
          an initial response from the origin server. Selection is based on a list of the available representations of the response
-         included within the header fields or entity-body of the initial response, with each representation identified by its own URI.
-         Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually
-         by the user selecting from a generated (possibly hypertext) menu.
+         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
+         from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the
+         user selecting from a generated (possibly hypertext) menu.
       </p>
       <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
@@ -1005 +1004 @@
          for an in-line image.
       </p>
-      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
+      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
   <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
   
@@ -1030 +1029 @@
       </div>
       <p id="rfc.section.5.1.p.6">The example</p>
-      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
+      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
          quality."
@@ -1039 +1038 @@
       </p>
       <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
-      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
+      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
           text/x-dvi; q=0.8, text/x-c
 </pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
@@ -1047 +1046 @@
          to a given type, the most specific reference has precedence. For example,
       </p>
-      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
+      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
 </pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
       <ol>
@@ -1058 +1057 @@
          which matches that type. For example,
       </p>
-      <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
           text/html;level=2;q=0.4, */*;q=0.5
 </pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
@@ -1107 +1106 @@
          to a server which is capable of representing documents in those character sets.
       </p>
-      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
           <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a>
   <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
@@ -1114 +1113 @@
          example is
       </p>
-      <div id="rfc.figure.u.21"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+      <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
 </pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
          not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
@@ -1128 +1127 @@
       <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
       </p>
-      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
                      <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>
   <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>  = 
@@ -1136 +1135 @@
       </p>
       <p id="rfc.section.5.3.p.4">Examples of its use are:</p>
-      <div id="rfc.figure.u.23"></div><pre class="text">  Accept-Encoding: compress, gzip
+      <div id="rfc.figure.u.22"></div><pre class="text">  Accept-Encoding: compress, gzip
   Accept-Encoding:
   Accept-Encoding: *
@@ -1180 +1179 @@
          in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
       </p>
-      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
                     <a href="#header.accept-language" class="smpl">Accept-Language-v</a>
   <a href="#header.accept-language" class="smpl">Accept-Language-v</a> =
@@ -1189 +1188 @@
          languages specified by that range. The quality value defaults to "q=1". For example,
       </p>
-      <div id="rfc.figure.u.25"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
+      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
       </p>
@@ -1218 +1217 @@
          is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
       </p>
-      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
+      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
   <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
 </pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
       </p>
-      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
+      <div id="rfc.figure.u.26"></div><pre class="text">  Content-Encoding: gzip
 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
          and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
@@ -1229 +1228 @@
       <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;5.5</a>) that lists the non-identity content-coding(s) used.
       </p>
-      <p id="rfc.section.5.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
+      <p id="rfc.section.5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
       </p>
       <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
@@ -1237 +1236 @@
       <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
       <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.
-         Note that this might not be equivalent to all the languages used within the entity-body.
-      </p>
-      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
+         Note that this might not be equivalent to all the languages used within the representation.
+      </p>
+      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
   <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
 </pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
@@ -1245 +1244 @@
          field is
       </p>
-      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
+      <div id="rfc.figure.u.28"></div><pre class="text">  Content-Language: da
 </pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
          that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
@@ -1253 +1252 @@
          simultaneously in the original Maori and English versions, would call for
       </p>
-      <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
+      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
@@ -1267 +1266 @@
          would contain the same representation that is enclosed as payload in this message.
       </p>
-      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
                     <a href="#header.content-location" class="smpl">Content-Location-v</a>
   <a href="#header.content-location" class="smpl">Content-Location-v</a> =
@@ -1308 +1307 @@
       <div id="rfc.iref.h.8"></div>
       <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
-      <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body that provides an end-to-end message integrity check (MIC) of the entity-body. Note that
-         a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.
-      </p>
-      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
+      <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
+         message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload
+         body in transit, but is not proof against malicious attacks.
+      </p>
+      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
   <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>&gt;
-</pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including
-         gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received.
-      </p>
-      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but
-         not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that
-         encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation.
-      </p>
-      <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would
-         be sent if no transfer-encoding were being applied.
-      </p>
-      <p id="rfc.section.5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
+</pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
+         agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
+      </p>
+      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
+         applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response
+         chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload.
+      </p>
+      <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
          but this does not change how the digest is computed as defined in the preceding paragraph.
       </p>
-      <p id="rfc.section.5.8.p.7">There are several consequences of this. The entity-body for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
+      <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
          headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
          body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
          The Transfer-Encoding header field is not allowed within body-parts.
       </p>
-      <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
-      </p>
-      <div class="note" id="rfc.section.5.8.p.9"> 
+      <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
+      </p>
+      <div class="note" id="rfc.section.5.8.p.8"> 
          <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
             ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
@@ -1345 +1342 @@
       <div id="rfc.iref.h.9"></div>
       <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
-      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. 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>
-      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
+      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-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>
+      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
   <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a>
 </pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
       </p>
-      <div id="rfc.figure.u.34"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
-</pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
+      <div id="rfc.figure.u.33"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
+</pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
       </p>
       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
@@ -1715 +1712 @@
                <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
       </div>
-      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1>
-      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045
-         discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully
-         chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date
-         comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
-      </p>
-      <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
+      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
+      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
+         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
+         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
+         to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
+      </p>
+      <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
          to HTTP also need to be aware of the differences because some conversions might be required.
       </p>
@@ -1732 +1729 @@
          environments.
       </p>
-      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
+      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
   <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this
@@ -1738 +1735 @@
       </p>
       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
-      <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
+      <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
          break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
          over HTTP.
@@ -1754 +1751 @@
       </p>
       <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
-      <p id="rfc.section.A.4.p.1">RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier
-         on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental
-         applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
-         a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).
+      <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
+         the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
+         experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
+         to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
       </p>
       <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
-      <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
+      <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
       </p>
       <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
@@ -1790 +1787 @@
          in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
       </p>
-      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
                         <a href="#content-disposition" class="smpl">content-disposition-v</a>
   <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a>
@@ -1800 +1797 @@
   <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a>
 </pre><p id="rfc.section.B.1.p.3">An example is</p>
-      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
+      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply
          to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only.
@@ -1830 +1827 @@
       </p>
       <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
-      <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
+      <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v
 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
@@ -1887 +1884 @@
 <a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token
 
-<a href="#entity.body" class="smpl">entity-body</a> = *OCTET
 <a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length
  / Content-Location / Content-MD5 / Content-Range / Content-Type /
@@ -1918 +1914 @@
 
 <a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
-</pre> <div id="rfc.figure.u.39"></div>
+</pre> <div id="rfc.figure.u.38"></div>
       <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
 ; Accept-Charset defined but not used
@@ -1925 +1921 @@
 ; MIME-Version defined but not used
 ; content-disposition defined but not used
-; entity-body defined but not used
 ; entity-header defined but not used
 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
@@ -2140 +2135 @@
                   <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul class="ind">
-                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
-                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.2</b></a></li>
-                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
-                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
-                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
-                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
-                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li>
+                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
+                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li>
+                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
+                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li>
+                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
+                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
                         <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
                         <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
-                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.3</b></a></li>
+                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
                         <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
-                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
-                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.5</b></a></li>
-                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
-                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.6</b></a></li>
-                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
-                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.7</b></a></li>
-                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
-                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.8</b></a></li>
-                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
-                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>5.9</b></a></li>
-                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>entity-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
+                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
+                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li>
+                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
+                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li>
+                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
+                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li>
+                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
+                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li>
+                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
+                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
                         <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li>
                         <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li>
-                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.4</b></a></li>
+                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
                         <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
-                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
                         <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
-                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
-                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>A.1</b></a></li>
+                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li>
+                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
                         <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
                         <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
@@ -2274 +2268 @@
                   <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>
                   <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>
+                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
                   <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
                         <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>