Ignore:
Timestamp:
Jul 22, 2010, 10:43:59 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r868 r875  
    377377      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    378378      <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2">
    379       <link rel="Chapter" title="3 Entity" href="#rfc.section.3">
     379      <link rel="Chapter" title="3 Representation" href="#rfc.section.3">
    380380      <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4">
    381381      <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
     
    384384      <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
    385385      <link rel="Chapter" href="#rfc.section.9" title="9 References">
    386       <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A">
     386      <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
    387387      <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
    388388      <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C">
     
    555555            </ul>
    556556         </li>
    557          <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#entity">Entity</a><ul class="toc">
     557         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
    558558               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#entity.header.fields">Entity Header Fields</a></li>
    559                <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#entity.body">Entity Body</a><ul class="toc">
     559               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a><ul class="toc">
    560560                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
    561561                  </ul>
     
    597597         </li>
    598598         <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
    599          <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">
     599         <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul class="toc">
    600600               <li class="tocline1">A.1&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li>
    601601               <li class="tocline1">A.2&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
     
    818818      </p>
    819819      <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>
    820       <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
    821          paragraph.
     820      <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.
    822821      </p>
    823822      <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
    824823         allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
    825          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
    826          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
    827          some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent
    828          the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body;
    829          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).
    830       </p>
    831       <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.
    832       </p>
    833       <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
    834          to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or
    835          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.
     824         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
     825         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
     826         character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the
     827         equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload
     828         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).
     829      </p>
     830      <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.
     831      </p>
     832      <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
     833         to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1"
     834         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.
    836835      </p>
    837836      <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>
    838       <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
    839          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.
     837      <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.
     838         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.
    840839      </p>
    841840      <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
     
    866865</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.
    867866      </p>
    868       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="entity" href="#entity">Entity</a></h1>
     867      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    869868      <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
    870869         of entity-header fields and a representation body, although some responses will only include the entity-headers.
     
    874873      </p>
    875874      <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>
    876       <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
    877          request.
     875      <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
     876         present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the
     877         Effective Request URI.
    878878      </p>
    879879      <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>
     
    892892         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.
    893893      </p>
    894       <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>
    895       <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>
    896       <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>
    897 </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
     894      <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>
     895      <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>
     896      <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
    898897         safe and proper transfer of the message.
    899898      </p>
    900899      <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>
    901       <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
     900      <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
    902901         and Content-Encoding. These define a two-layer, ordered encoding model:
    903902      </p>
    904       <div id="rfc.figure.u.14"></div><pre class="text">  entity-body := Content-Encoding( Content-Type( data ) )
    905 </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.
     903      <div id="rfc.figure.u.13"></div><pre class="text">  payload-body := Content-Encoding( Content-Type( data ) )
     904</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.
    906905      </p>
    907906      <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.
     
    911910         the specified type.
    912911      </p>
    913       <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").
     912      <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").
    914913         Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
    915914      </p>
    916915      <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
    917          compression, that are a property of the requested resource. There is no default encoding.
     916         compression, that are a property of the representation. There is no default encoding.
    918917      </p>
    919918      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
     
    977976      <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
    978977         an initial response from the origin server. Selection is based on a list of the available representations of the response
    979          included within the header fields or entity-body of the initial response, with each representation identified by its own URI.
    980          Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually
    981          by the user selecting from a generated (possibly hypertext) menu.
     978         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     979         from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the
     980         user selecting from a generated (possibly hypertext) menu.
    982981      </p>
    983982      <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,
     
    10051004         for an in-line image.
    10061005      </p>
    1007       <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>
     1006      <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>
    10081007  <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> ] )
    10091008 
     
    10301029      </div>
    10311030      <p id="rfc.section.5.1.p.6">The example</p>
    1032       <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
     1031      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    10331032</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
    10341033         quality."
     
    10391038      </p>
    10401039      <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
    1041       <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
     1040      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10421041          text/x-dvi; q=0.8, text/x-c
    10431042</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
     
    10471046         to a given type, the most specific reference has precedence. For example,
    10481047      </p>
    1049       <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
     1048      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
    10501049</pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
    10511050      <ol>
     
    10581057         which matches that type. For example,
    10591058      </p>
    1060       <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     1059      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10611060          text/html;level=2;q=0.4, */*;q=0.5
    10621061</pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
     
    11071106         to a server which is capable of representing documents in those character sets.
    11081107      </p>
    1109       <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>
     1108      <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>
    11101109          <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a>
    11111110  <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
     
    11141113         example is
    11151114      </p>
    1116       <div id="rfc.figure.u.21"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     1115      <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    11171116</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
    11181117         not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
     
    11281127      <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.
    11291128      </p>
    1130       <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>
     1129      <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>
    11311130                     <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>
    11321131  <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>  =
     
    11361135      </p>
    11371136      <p id="rfc.section.5.3.p.4">Examples of its use are:</p>
    1138       <div id="rfc.figure.u.23"></div><pre class="text">  Accept-Encoding: compress, gzip
     1137      <div id="rfc.figure.u.22"></div><pre class="text">  Accept-Encoding: compress, gzip
    11391138  Accept-Encoding:
    11401139  Accept-Encoding: *
     
    11801179         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    11811180      </p>
    1182       <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>
     1181      <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>
    11831182                    <a href="#header.accept-language" class="smpl">Accept-Language-v</a>
    11841183  <a href="#header.accept-language" class="smpl">Accept-Language-v</a> =
     
    11891188         languages specified by that range. The quality value defaults to "q=1". For example,
    11901189      </p>
    1191       <div id="rfc.figure.u.25"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     1190      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    11921191</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>)
    11931192      </p>
     
    12181217         is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
    12191218      </p>
    1220       <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>
     1219      <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>
    12211220  <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    12221221</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
    12231222      </p>
    1224       <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
     1223      <div id="rfc.figure.u.26"></div><pre class="text">  Content-Encoding: gzip
    12251224</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
    12261225         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
     
    12291228      <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.
    12301229      </p>
    1231       <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).
     1230      <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).
    12321231      </p>
    12331232      <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.
     
    12371236      <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>
    12381237      <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.
    1239          Note that this might not be equivalent to all the languages used within the entity-body.
    1240       </p>
    1241       <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>
     1238         Note that this might not be equivalent to all the languages used within the representation.
     1239      </p>
     1240      <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>
    12421241  <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    12431242</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
     
    12451244         field is
    12461245      </p>
    1247       <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
     1246      <div id="rfc.figure.u.28"></div><pre class="text">  Content-Language: da
    12481247</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
    12491248         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
     
    12531252         simultaneously in the original Maori and English versions, would call for
    12541253      </p>
    1255       <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
     1254      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
    12561255</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
    12571256         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
     
    12671266         would contain the same representation that is enclosed as payload in this message.
    12681267      </p>
    1269       <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>
     1268      <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>
    12701269                    <a href="#header.content-location" class="smpl">Content-Location-v</a>
    12711270  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
     
    13081307      <div id="rfc.iref.h.8"></div>
    13091308      <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>
    1310       <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
    1311          a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.
    1312       </p>
    1313       <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>
     1309      <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
     1310         message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload
     1311         body in transit, but is not proof against malicious attacks.
     1312      </p>
     1313      <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>
    13141314  <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;
    1315 </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
    1316          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.
    1317       </p>
    1318       <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
    1319          not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that
    1320          encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation.
    1321       </p>
    1322       <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
    1323          be sent if no transfer-encoding were being applied.
    1324       </p>
    1325       <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),
     1315</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
     1316         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.
     1317      </p>
     1318      <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
     1319         applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response
     1320         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.
     1321      </p>
     1322      <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),
    13261323         but this does not change how the digest is computed as defined in the preceding paragraph.
    13271324      </p>
    1328       <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
     1325      <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
    13291326         headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
    13301327         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.
    13311328         The Transfer-Encoding header field is not allowed within body-parts.
    13321329      </p>
    1333       <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.
    1334       </p>
    1335       <div class="note" id="rfc.section.5.8.p.9">
     1330      <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.
     1331      </p>
     1332      <div class="note" id="rfc.section.5.8.p.8">
    13361333         <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
    13371334            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
     
    13451342      <div id="rfc.iref.h.9"></div>
    13461343      <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>
    1347       <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,
    1348          the media type is that which would have been sent had the request been a GET.
    1349       </p>
    1350       <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>
     1344      <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
     1345         method, the media type is that which would have been sent had the request been a GET.
     1346      </p>
     1347      <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>
    13511348  <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a>
    13521349</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
    13531350      </p>
    1354       <div id="rfc.figure.u.34"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    1355 </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>.
     1351      <div id="rfc.figure.u.33"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
     1352</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>.
    13561353      </p>
    13571354      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     
    17151712               <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>
    17161713      </div>
    1717       <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>
    1718       <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
    1719          discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully
    1720          chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date
    1721          comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
    1722       </p>
    1723       <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
     1714      <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>
     1715      <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,
     1716         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
     1717         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
     1718         to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
     1719      </p>
     1720      <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
    17241721         to HTTP also need to be aware of the differences because some conversions might be required.
    17251722      </p>
     
    17321729         environments.
    17331730      </p>
    1734       <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>
     1731      <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>
    17351732  <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>
    17361733</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
     
    17381735      </p>
    17391736      <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>
    1740       <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
     1737      <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
    17411738         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    17421739         over HTTP.
     
    17541751      </p>
    17551752      <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>
    1756       <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
    1757          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
    1758          applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    1759          a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).
     1753      <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
     1754         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
     1755         experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
     1756         to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
    17601757      </p>
    17611758      <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>
    1762       <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.
     1759      <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.
    17631760      </p>
    17641761      <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
     
    17901787         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>.
    17911788      </p>
    1792       <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>
     1789      <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>
    17931790                        <a href="#content-disposition" class="smpl">content-disposition-v</a>
    17941791  <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a>
     
    18001797  <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>
    18011798</pre><p id="rfc.section.B.1.p.3">An example is</p>
    1802       <div id="rfc.figure.u.37"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
     1799      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
    18031800</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
    18041801         to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only.
     
    18301827      </p>
    18311828      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    1832       <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
     1829      <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
    18331830<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v
    18341831<a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
     
    18871884<a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token
    18881885
    1889 <a href="#entity.body" class="smpl">entity-body</a> = *OCTET
    18901886<a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length
    18911887 / Content-Location / Content-MD5 / Content-Range / Content-Type /
     
    19181914
    19191915<a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
    1920 </pre> <div id="rfc.figure.u.39"></div>
     1916</pre> <div id="rfc.figure.u.38"></div>
    19211917      <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
    19221918; Accept-Charset defined but not used
     
    19251921; MIME-Version defined but not used
    19261922; content-disposition defined but not used
    1927 ; entity-body defined but not used
    19281923; entity-header defined but not used
    19291924</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>
     
    21402135                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    21412136                     <ul class="ind">
    2142                         <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
    2143                         <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
    2144                         <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.2</b></a></li>
    2145                         <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
    2146                         <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
    2147                         <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.1</b></a></li>
    2148                         <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
    2149                         <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
    2150                         <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
    2151                         <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
     2137                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li>
     2138                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li>
     2139                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
     2140                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li>
     2141                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
     2142                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
     2143                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li>
     2144                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
     2145                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
     2146                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
    21522147                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
    21532148                        <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
    2154                         <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.3</b></a></li>
     2149                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
    21552150                        <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
    2156                         <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
    2157                         <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
    2158                         <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
    2159                         <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.5</b></a></li>
    2160                         <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
    2161                         <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.6</b></a></li>
    2162                         <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
    2163                         <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.7</b></a></li>
    2164                         <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
    2165                         <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.8</b></a></li>
    2166                         <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
    2167                         <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>5.9</b></a></li>
    2168                         <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>B.1</b></a></li>
    2169                         <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
    2170                         <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
    2171                         <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
    2172                         <li class="indline1"><tt>entity-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>3.2</b></a></li>
     2151                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
     2152                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
     2153                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
     2154                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
     2155                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li>
     2156                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
     2157                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li>
     2158                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
     2159                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li>
     2160                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
     2161                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li>
     2162                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
     2163                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
     2164                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
     2165                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
     2166                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
    21732167                        <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li>
    21742168                        <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li>
    2175                         <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
    2176                         <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.4</b></a></li>
     2169                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
     2170                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
    21772171                        <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
    2178                         <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
     2172                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
    21792173                        <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
    2180                         <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
    2181                         <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>A.1</b></a></li>
     2174                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li>
     2175                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
    21822176                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
    21832177                        <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
     
    22742268                  <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>
    22752269                  <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>
    2276                   <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>
     2270                  <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>
    22772271                  <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">
    22782272                        <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>
Note: See TracChangeset for help on using the changeset viewer.