Ignore:
Timestamp:
05/01/13 07:12:36 (10 years ago)
Author:
fielding@…
Message:

Requirements are not allowed in appendices. They have been changed to prose.
Changes from RFC2616 have been rewritten for consistency and to remove changes
that are only editorial. Addresses #419

Location:
draft-ietf-httpbis/latest
Files:
5 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r2082 r2083  
    4141Last-Modified = HTTP-date
    4242Location = URI-reference
    43 MIME-Version = 1*DIGIT "." 1*DIGIT
    4443Max-Forwards = 1*DIGIT
    4544OWS = *( SP / HTAB )
    … …  
    264263; Last-Modified defined but not used
    265264; Location defined but not used
    266 ; MIME-Version defined but not used
    267265; Max-Forwards defined but not used
    268266; Pragma defined but not used

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2081 r2083  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 6, 2013";
     451       content: "Expires July 8, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">January 2, 2013</td>
     522               <td class="right">January 4, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: July 6, 2013</td>
     525               <td class="left">Expires: July 8, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on July 6, 2013.</p>
     553      <p>This Internet-Draft will expire on July 8, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    707707      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    708708      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    709          MIME-like message payloads for flexible interaction with network-based hypertext information systems. This document is the
    710          first in a series of documents that collectively form the HTTP/1.1 specification:
     709         self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document
     710         is the first in a series of documents that collectively form the HTTP/1.1 specification:
    711711      </p>
    712712      <ul class="empty">
    … …  
    27922792      </p>
    27932793      <h3 id="rfc.section.A.1.3"><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3>
    2794       <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer coding prior to forwarding a message via a MIME-compliant protocol.
     2794      <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>). Transfer codings need to be decoded prior to forwarding an HTTP message over a MIME-compliant protocol.
    27952795      </p>
    27962796      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2081 r2083  
    143143<t>
    144144   The Hypertext Transfer Protocol (HTTP) is an application-level
    145    request/response protocol that uses extensible semantics and MIME-like
     145   request/response protocol that uses extensible semantics and self-descriptive
    146146   message payloads for flexible interaction with network-based hypertext
    147147   information systems. This document is the first in a series of documents
    … …  
    46764676<t>
    46774677   HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field
    4678    (<xref target="header.transfer-encoding"/>). Proxies/gateways &MUST; remove
    4679    any transfer coding prior to forwarding a message via a MIME-compliant
    4680    protocol.
     4678   (<xref target="header.transfer-encoding"/>).
     4679   Transfer codings need to be decoded prior to forwarding an HTTP message
     4680   over a MIME-compliant protocol.
    46814681</t>
    46824682</section>

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

    r2082 r2083  
    483483      <link rel="Chapter" href="#rfc.section.11" title="11 References">
    484484      <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
    485       <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
    486       <link rel="Appendix" title="C Changes from RFC 2616" href="#rfc.section.C">
    487       <link rel="Appendix" title="D Imported ABNF" href="#rfc.section.D">
    488       <link rel="Appendix" title="E Collected ABNF" href="#rfc.section.E">
    489       <link rel="Appendix" title="F Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.F">
     485      <link rel="Appendix" title="B Significant changes from RFC 2616" href="#rfc.section.B">
     486      <link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C">
     487      <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
     488      <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E">
    490489      <link href="p1-messaging.html" rel="prev">
    491490      <link href="p4-conditional.html" rel="next">
    … …  
    543542      <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
    544543      </p> 
    545       <p>The changes in this draft are summarized in <a href="#changes.since.21" title="Since draft-ietf-httpbis-p2-semantics-21">Appendix&nbsp;F.2</a>.
     544      <p>The changes in this draft are summarized in <a href="#changes.since.21" title="Since draft-ietf-httpbis-p2-semantics-21">Appendix&nbsp;E.2</a>.
    546545      </p>
    547546      <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    … …  
    785784               <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
    786785               <li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li>
    787                <li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li>
    788                <li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li>
     786               <li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-encoding">Conversion of Content-Encoding</a></li>
     787               <li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></li>
    789788               <li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li>
    790789            </ul>
    791790         </li>
    792          <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#additional.features">Additional Features</a></li>
    793          <li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    794          <li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li>
    795          <li><a href="#rfc.section.E">E.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
    796          <li><a href="#rfc.section.F">F.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
    797                <li><a href="#rfc.section.F.1">F.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F.1">Since RFC 2616</a></li>
    798                <li><a href="#rfc.section.F.2">F.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.21">Since draft-ietf-httpbis-p2-semantics-21</a></li>
     791         <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Significant changes from RFC 2616</a></li>
     792         <li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li>
     793         <li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
     794         <li><a href="#rfc.section.E">E.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
     795               <li><a href="#rfc.section.E.1">E.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.1">Since RFC 2616</a></li>
     796               <li><a href="#rfc.section.E.2">E.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.21">Since draft-ietf-httpbis-p2-semantics-21</a></li>
    799797            </ul>
    800798         </li>
    … …  
    824822      </p>
    825823      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    826       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;D</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;E</a> shows the collected ABNF with the list rule expanded.
     824      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected ABNF with the list rule expanded.
    827825      </p>
    828826      <p id="rfc.section.1.2.p.2">This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are
    … …  
    926924      <p id="rfc.section.3.1.1.3.p.1">Internet media types are registered with a canonical form in order to be interoperable among systems with varying native encoding
    927925         formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described
    928          by MIME <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly
     926         by 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>. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly
    929927         different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the
    930928         sake of compatibility with older mail transfer protocols do not apply to HTTP (see <a href="#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix&nbsp;A</a>).
    … …  
    25892587      <div id="rfc.iref.73"></div>
    25902588      <h3 id="rfc.section.6.4.5"><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
    2591       <p id="rfc.section.6.4.5.p.1">The <dfn>305 (Use Proxy)</dfn> status code was defined in a previous version of this specification and is now deprecated (<a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;C</a>).
     2589      <p id="rfc.section.6.4.5.p.1">The <dfn>305 (Use Proxy)</dfn> status code was defined in a previous version of this specification and is now deprecated (<a href="#changes.from.rfc.2616" title="Significant changes from RFC 2616">Appendix&nbsp;B</a>).
    25922590      </p>
    25932591      <div id="rfc.iref.73"></div>
    … …  
    39373935      <h2 id="rfc.references.2"><a href="#rfc.section.11.2" id="rfc.section.11.2">11.2</a> Informative References
    39383936      </h2>
    3939       <table>                                           
     3937      <table>                                       
    39403938         <tr>
    39413939            <td class="reference"><b id="BCP13">[BCP13]</b></td>
    … …  
    39713969            <td class="reference"><b id="RFC2068">[RFC2068]</b></td>
    39723970            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.
    3973             </td>
    3974          </tr>
    3975          <tr>
    3976             <td class="reference"><b id="RFC2076">[RFC2076]</b></td>
    3977             <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC&nbsp;2076, February&nbsp;1997.
    39783971            </td>
    39793972         </tr>
    … …  
    40294022         </tr>
    40304023         <tr>
    4031             <td class="reference"><b id="RFC6151">[RFC6151]</b></td>
    4032             <td class="top">Turner, S. and L. Chen, “<a href="http://tools.ietf.org/html/rfc6151">Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</a>”, RFC&nbsp;6151, March&nbsp;2011.
    4033             </td>
    4034          </tr>
    4035          <tr>
    40364024            <td class="reference"><b id="RFC6265">[RFC6265]</b></td>
    40374025            <td class="top"><a href="mailto:abarth@eecs.berkeley.edu" title="&#xA;        University of California, Berkeley&#xA;      ">Barth, A.</a>, “<a href="http://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a>”, RFC&nbsp;6265, April&nbsp;2011.
    … …  
    40594047      </div>
    40604048      <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>
    4061       <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.7"><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,
    4062          RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
    4063          carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
    4064          to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
    4065       </p>
    4066       <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
    4067          to HTTP also need to be aware of the differences because some conversions might be required.
     4049      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.7"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.2"><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 header fields. However,
     4050         RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email, and hence HTTP has
     4051         features that differ from MIME. These differences were carefully chosen to optimize performance over binary connections, to
     4052         allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some
     4053         early HTTP servers and clients.
     4054      </p>
     4055      <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to and from strict MIME environments
     4056         need to be aware of these differences and provide the appropriate conversions where necessary.
    40684057      </p>
    40694058      <div id="rfc.iref.m.2"></div>
    40704059      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="mime-version" href="#mime-version">MIME-Version</a></h2>
    4071       <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.
    4072          Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined
    4073          in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict
    4074          MIME environments.
    4075       </p>
    4076       <div id="rfc.figure.u.64"></div><pre class="inline"><span id="rfc.iref.g.62"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> "." 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    4077 </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
    4078          document and not the MIME specification.
     4060      <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version
     4061         of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is
     4062         in full conformance with the MIME protocol (as defined in <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>). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.
    40794063      </p>
    40804064      <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>
    4081       <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.2"><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;3.1.1.3</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
    4082          break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    4083          over HTTP.
    4084       </p>
    4085       <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
     4065      <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;3.1.1.3</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
     4066         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content.
     4067      </p>
     4068      <p id="rfc.section.A.2.p.2">A proxy or gateway from HTTP to a strict MIME environment ought to translate all line breaks within the text media types described
     4069        in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
    40864070      </p>
    40874071      <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
    … …  
    40894073      </p>
    40904074      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    4091       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any <a href="#header.date" class="smpl">Date</a> header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    4092       </p>
    4093       <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>
    4094       <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's <a href="#header.content-encoding" class="smpl">Content-Encoding</a> 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 <a href="#header.content-type" class="smpl">Content-Type</a> header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for
     4075      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols ought to ensure that any <a href="#header.date" class="smpl">Date</a> header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     4076      </p>
     4077      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="conversion.content-encoding" href="#conversion.content-encoding">Conversion of Content-Encoding</a></h2>
     4078      <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's <a href="#header.content-encoding" class="smpl">Content-Encoding</a> header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols
     4079         ought to either change the value of the <a href="#header.content-type" class="smpl">Content-Type</a> header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for
    40954080         Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform a function equivalent to Content-Encoding.
    40964081         However, this parameter is not part of the MIME standards).
    40974082      </p>
    40984083      <div id="rfc.iref.c.10"></div>
    4099       <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>
    4100       <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.
     4084      <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="conversion.content-transfer-encoding" href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></h2>
     4085      <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
     4086         need to remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
    41014087      </p>
    41024088      <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
    41034089         format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol
    4104          being used. Such a proxy or gateway <em class="bcp14">SHOULD</em> label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over
    4105          the destination protocol.
     4090         being used. Such a proxy or gateway ought to transform and label the data with an appropriate Content-Transfer-Encoding if
     4091         doing so will improve the likelihood of safe transport over the destination protocol.
    41064092      </p>
    41074093      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    41084094      <p id="rfc.section.A.6.p.1">HTTP implementations that share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
    41094095         fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
    4110          and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;3.1.1.4</a>) and does not interpret the content or any MIME header lines that might be contained therein.
    4111       </p>
    4112       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="additional.features" href="#additional.features">Additional Features</a></h1>
    4113       <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
    4114          applications. Implementers are advised to be aware of these features, but cannot rely upon their presence in, or interoperability
    4115          with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that
    4116          experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
    4117       </p>
    4118       <p id="rfc.section.B.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a> and <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
    4119       </p>
    4120       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    4121       <p id="rfc.section.C.p.1">Request semantics embedded in a URI should be disabled when those semantics are inconsistent with the request method, since
    4122          this is a common cause of interoperability failure.
    4123       </p>
    4124       <p id="rfc.section.C.p.2">The term "representation" is introduced, replacing both "entity" and "variant." (<a href="#representations" title="Representations">Section&nbsp;3</a>)
    4125       </p>
    4126       <p id="rfc.section.C.p.3">Rules for identifying the payload of a message have been defined. (<a href="#identifying.payload" title="Identifying a Representation">Section&nbsp;3.1.4.1</a>)
    4127       </p>
    4128       <p id="rfc.section.C.p.4">"Server-Driven" and "agent-driven" content negotiation are now called "proactive" and "reactive" content negotiation (respectively).
    4129          (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>)
    4130       </p>
    4131       <p id="rfc.section.C.p.5"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus
    4132          Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated
    4133          resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
    4134       </p>
    4135       <p id="rfc.section.C.p.6">GET requests can have a body; it just has no meaning. (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>)
    4136       </p>
    4137       <p id="rfc.section.C.p.7">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>)
    4138       </p>
    4139       <p id="rfc.section.C.p.8">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>)
    4140       </p>
    4141       <p id="rfc.section.C.p.9">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section&nbsp;4.3.4</a>)
    4142       </p>
    4143       <p id="rfc.section.C.p.10">The CONNECT method is now defined by this specification, taking over from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;4.3.6</a>)
    4144       </p>
    4145       <p id="rfc.section.C.p.11">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section&nbsp;4.3.6</a>)
    4146       </p>
    4147       <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section&nbsp;4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>)
    4148       </p>
    4149       <p id="rfc.section.C.p.13">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well).
    4150          (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;5.1.1</a>)
    4151       </p>
    4152       <p id="rfc.section.C.p.14">The ABNF for the "<a href="#header.expect" class="smpl">Expect</a>" header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing
    4153          semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;5.1.2</a>)
    4154       </p>
    4155       <p id="rfc.section.C.p.15">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;5.3.3</a>)
    4156       </p>
    4157       <p id="rfc.section.C.p.16">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section&nbsp;7.1.1.2</a>)
    4158       </p>
    4159       <p id="rfc.section.C.p.17">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.4" title="Referer">Section&nbsp;5.5.2</a>)
    4160       </p>
    4161       <p id="rfc.section.C.p.18">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one).
    4162       </p>
    4163       <p id="rfc.section.C.p.19">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;6.3.4</a>)
    4164       </p>
    4165       <p id="rfc.section.C.p.20">Redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;6.4</a>)
    4166       </p>
    4167       <p id="rfc.section.C.p.21">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination
    4168          based upon the request method semantics. (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section&nbsp;6.4</a>)
    4169       </p>
    4170       <p id="rfc.section.C.p.22">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications
    4171          as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section&nbsp;7.1.2</a>)
    4172       </p>
    4173       <p id="rfc.section.C.p.23">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section&nbsp;6.4.4</a>)
    4174       </p>
    4175       <p id="rfc.section.C.p.24">User agents are now allowed to rewrite the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">6.4.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">6.4.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">6.4.7</a>)
    4176       </p>
    4177       <p id="rfc.section.C.p.25">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed
    4178          to be accessed through the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The recipient was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;6.4.5</a>)
    4179       </p>
    4180       <p id="rfc.section.C.p.26">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section&nbsp;6.5.1</a>)
    4181       </p>
    4182       <p id="rfc.section.C.p.27">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section&nbsp;6.5.3</a>)
    4183       </p>
    4184       <p id="rfc.section.C.p.28">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;6.5.15</a>)
    4185       </p>
    4186       <p id="rfc.section.C.p.29"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;7.4.1</a>)
    4187       </p>
    4188       <p id="rfc.section.C.p.30">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always
    4189          trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;7.4.1</a>)
    4190       </p>
    4191       <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;7.4.2</a>)
    4192       </p>
    4193       <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>)
    4194       </p>
    4195       <p id="rfc.section.C.p.33">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition
    4196          says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a>)
    4197       </p>
    4198       <p id="rfc.section.C.p.34">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;8.4</a>)
    4199       </p>
    4200       <p id="rfc.section.C.p.35">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses,
    4201          and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details).
    4202       </p>
    4203       <p id="rfc.section.C.p.36">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;8.1</a>)
    4204       </p>
    4205       <p id="rfc.section.C.p.37">The Status Code Registry is now defined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;8.2</a>)
    4206       </p>
    4207       <p id="rfc.section.C.p.38">References to the "identity" transfer coding token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    4208       </p>
    4209       <p id="rfc.section.C.p.39">The Content-Disposition header field is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
    4210       </p>
    4211       <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    4212       <p id="rfc.section.D.p.1">The following core rules are included by reference, as defined in <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
     4096         and folding, canonicalization, etc., since HTTP transfers message-bodies as payload and, aside from the "multipart/byteranges"
     4097         type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), does not interpret the content or any MIME header lines that might be contained therein.
     4098      </p>
     4099      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Significant changes from RFC 2616</a></h1>
     4100      <p id="rfc.section.B.p.1">The primary changes in this revision have been editorial in nature: extracting the messaging syntax and partitioning HTTP
     4101         semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication.
     4102         The conformance language has been revised to clearly target requirements and the terminology has been improved to distinguish
     4103         payload from representations and representations from resources. An algorithm has been added for determining if a payload
     4104         is associated with a specific identifier (<a href="#identifying.payload" title="Identifying a Representation">Section&nbsp;3.1.4.1</a>).
     4105      </p>
     4106      <p id="rfc.section.B.p.2">A new requirement has been added that semantics embedded in a URI should be disabled when those semantics are inconsistent
     4107         with the request method, since this is a common cause of interoperability failure.
     4108      </p>
     4109      <p id="rfc.section.B.p.3">The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition
     4110         says (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a>). Likewise, special treatment of ISO-8859-1 has been removed from the <a href="#header.accept-charset" class="smpl">Accept-Charset</a> header field (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;5.3.3</a>).
     4111      </p>
     4112      <p id="rfc.section.B.p.4">The Content-Disposition header field has been removed since it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>.
     4113      </p>
     4114      <p id="rfc.section.B.p.5">The definition of <a href="#header.content-location" class="smpl">Content-Location</a> has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support
     4115         and the undesirable effect of potentially breaking relative links in content-negotiated resources (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>).
     4116      </p>
     4117      <p id="rfc.section.B.p.6">The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.</p>
     4118      <p id="rfc.section.B.p.7">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>).
     4119      </p>
     4120      <p id="rfc.section.B.p.8">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>).
     4121      </p>
     4122      <p id="rfc.section.B.p.9">Definition of the CONNECT method has been moved from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> to this specification (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;4.3.6</a>).
     4123      </p>
     4124      <p id="rfc.section.B.p.10">The <a href="#OPTIONS" class="smpl">OPTIONS</a> (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section&nbsp;4.3.7</a>) and <a href="#TRACE" class="smpl">TRACE</a> (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>) request methods have been defined as being safe.
     4125      </p>
     4126      <p id="rfc.section.B.p.11">The definition of <a href="#header.expect" class="smpl">Expect</a> has been both fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons after "100-continue"
     4127         (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;5.1.2</a>).
     4128      </p>
     4129      <p id="rfc.section.B.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;5.1.1</a>) has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well.
     4130      </p>
     4131      <p id="rfc.section.B.p.13">The "about:blank" URI has been suggested as a value for the <a href="#header.referer" class="smpl">Referer</a> header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not
     4132         sent or has been removed (<a href="#header.referer" id="rfc.xref.header.referer.4" title="Referer">Section&nbsp;5.5.2</a>).
     4133      </p>
     4134      <p id="rfc.section.B.p.14">The <a href="#status.201" class="smpl">201 (Created)</a> status description has been changed to allow for the possibility that more than one resource has been created (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section&nbsp;6.3.2</a>).
     4135      </p>
     4136      <p id="rfc.section.B.p.15">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;6.3.4</a>).
     4137      </p>
     4138      <p id="rfc.section.B.p.16">The redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;6.4</a>).
     4139      </p>
     4140      <p id="rfc.section.B.p.17">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination
     4141         based upon the request method semantics (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section&nbsp;6.4</a>).
     4142      </p>
     4143      <p id="rfc.section.B.p.18">The description of 303 (See Other) status code has been changed to allow it to be cached if explicit freshness information
     4144         is given, and a specific definition has been added for a 303 response to GET (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section&nbsp;6.4.4</a>).
     4145      </p>
     4146      <p id="rfc.section.B.p.19">The status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> (sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">6.4.2</a> and <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">6.4.3</a>) have been changed to allow user agents to rewrite the method from POST to GET.
     4147      </p>
     4148      <p id="rfc.section.B.p.20">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code has been deprecated due to security concerns regarding in-band configuration of a proxy (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;6.4.5</a>).
     4149      </p>
     4150      <p id="rfc.section.B.p.21">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been relaxed so that it isn't limited to syntax errors (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section&nbsp;6.5.1</a>).
     4151      </p>
     4152      <p id="rfc.section.B.p.22">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;6.5.15</a>).
     4153      </p>
     4154      <p id="rfc.section.B.p.23"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. Requirements relating
     4155         to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;7.4.1</a>).
     4156      </p>
     4157      <p id="rfc.section.B.p.24">The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date,
     4158         rather than all systems sending a date (<a href="#origination.date" title="Origination Date">Section&nbsp;7.1.1</a>).
     4159      </p>
     4160      <p id="rfc.section.B.p.25">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications
     4161         as to when use of fragments would not be appropriate (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section&nbsp;7.1.2</a>).
     4162      </p>
     4163      <p id="rfc.section.B.p.26">A Method Registry has been defined (<a href="#method.registry" title="Method Registry">Section&nbsp;8.1</a>).
     4164      </p>
     4165      <p id="rfc.section.B.p.27">The Status Code Registry (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;8.2</a>) has been redefined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>.
     4166      </p>
     4167      <p id="rfc.section.B.p.28">Registration of Content Codings has been changed to require IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;8.4</a>).
     4168      </p>
     4169      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
     4170      <p id="rfc.section.C.p.1">The following core rules are included by reference, as defined in <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
    42134171         (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR
    42144172         (any visible US-ASCII character).
    42154173      </p>
    4216       <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    4217       </p>
    4218       <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4174      <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     4175      </p>
     4176      <div id="rfc.figure.u.64"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    42194177  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    42204178  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    … …  
    42274185  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    42284186  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4229 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    4230       <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     4187</pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     4188      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    42314189 OWS ( media-range [ accept-params ] ) ] ) ]
    42324190<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
    … …  
    42614219<a href="#header.location" class="smpl">Location</a> = URI-reference
    42624220
    4263 <a href="#mime-version" class="smpl">MIME-Version</a> = 1*DIGIT "." 1*DIGIT
    42644221<a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT
    42654222
    … …  
    43664323
    43674324<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    4368 </pre> <h1 id="rfc.section.F"><a href="#rfc.section.F">F.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    4369       <h2 id="rfc.section.F.1"><a href="#rfc.section.F.1">F.1</a>&nbsp;Since RFC 2616
     4325</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>
     4326      <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC 2616
    43704327      </h2>
    4371       <p id="rfc.section.F.1.p.1">Changes up to the first Working Group Last Call draft are summarized in &lt;<a href="http://trac.tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#appendix-F">http://trac.tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#appendix-F</a>&gt;.
    4372       </p>
    4373       <h2 id="rfc.section.F.2"><a href="#rfc.section.F.2">F.2</a>&nbsp;<a id="changes.since.21" href="#changes.since.21">Since draft-ietf-httpbis-p2-semantics-21</a></h2>
    4374       <p id="rfc.section.F.2.p.1">Closed issues: </p>
     4328      <p id="rfc.section.E.1.p.1">Changes up to the first Working Group Last Call draft are summarized in &lt;<a href="http://trac.tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#appendix-F">http://trac.tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#appendix-F</a>&gt;.
     4329      </p>
     4330      <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a>&nbsp;<a id="changes.since.21" href="#changes.since.21">Since draft-ietf-httpbis-p2-semantics-21</a></h2>
     4331      <p id="rfc.section.E.2.p.1">Closed issues: </p>
    43754332      <ul>
    43764333         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/388">http://tools.ietf.org/wg/httpbis/trac/ticket/388</a>&gt;: "User confirmation for unsafe methods"
    … …  
    43954352            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    43964353                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">8.2.3</a></li>
    4397                   <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a></li>
     4354                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a>, <a href="#rfc.xref.status.201.3">B</a></li>
    43984355                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">8.2.3</a></li>
    4399                   <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">C</a></li>
     4356                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">B</a></li>
    44004357                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">8.2.3</a></li>
    44014358                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.72"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">8.2.3</a></li>
    … …  
    44054362            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    44064363                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">8.2.3</a></li>
    4407                   <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">C</a></li>
    4408                   <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">C</a></li>
    4409                   <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">C</a></li>
    4410                   <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">C</a></li>
     4364                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">B</a></li>
     4365                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">B</a></li>
     4366                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">B</a></li>
     4367                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">B</a></li>
    44114368                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.73"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li>
    4412                   <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a>, <a href="#rfc.xref.status.307.3">C</a></li>
    4413                   <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.72"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a>, <a href="#rfc.xref.status.3xx.2">C</a></li>
     4369                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.73"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li>
     4370                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.72"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a>, <a href="#rfc.xref.status.3xx.2">B</a></li>
    44144371               </ul>
    44154372            </li>
    44164373            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    4417                   <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">C</a></li>
     4374                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">B</a></li>
    44184375                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">8.2.3</a></li>
    4419                   <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a>, <a href="#rfc.xref.status.403.3">C</a></li>
     4376                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a></li>
    44204377                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">8.2.3</a></li>
    44214378                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">8.2.3</a></li>
    … …  
    44294386                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li>
    44304387                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">8.2.3</a></li>
    4431                   <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">C</a></li>
     4388                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">B</a></li>
    44324389                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.73"><b>6.5</b></a></li>
    44334390               </ul>
    … …  
    44454402            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    44464403                  <li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.1.1.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.3.2</a></li>
    4447                   <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3.2</a>, <a href="#rfc.xref.header.accept-charset.3">C</a></li>
     4404                  <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3.2</a>, <a href="#rfc.xref.header.accept-charset.3">B</a></li>
    44484405                  <li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.1.2.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.3.2</a>, <a href="#rfc.xref.header.accept-encoding.4">8.4.2</a></li>
    44494406                  <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.2">8.3.2</a></li>
    4450                   <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a>, <a href="#rfc.xref.header.allow.5">C</a></li>
     4407                  <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3.2</a>, <a href="#rfc.xref.header.allow.4">B</a></li>
    44514408               </ul>
    44524409            </li>
    … …  
    44594416                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>4.2.3</b></a></li>
    44604417                  <li>compress (content coding)&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>3.1.2.1</b></a></li>
    4461                   <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.9"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">8.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a>, <a href="#rfc.xref.CONNECT.4">C</a></li>
     4418                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.9"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">8.1.3</a>, <a href="#rfc.xref.CONNECT.3">B</a></li>
    44624419                  <li>content coding&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>3.1.2.1</b></a></li>
    44634420                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
    44644421                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.1</a>, <a href="#rfc.xref.header.content-encoding.2">3.1.2.1</a>, <a href="#rfc.iref.c.5"><b>3.1.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.3">8.3.2</a></li>
    44654422                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.1</a>, <a href="#rfc.iref.c.6"><b>3.1.3.2</b></a>, <a href="#rfc.xref.header.content-language.2">8.3.2</a></li>
    4466                   <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.7"><b>3.1.4.2</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.2</a>, <a href="#rfc.xref.header.content-location.4">8.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
    4467                   <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.10">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
     4423                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.7"><b>3.1.4.2</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.2</a>, <a href="#rfc.xref.header.content-location.4">8.3.2</a>, <a href="#rfc.xref.header.content-location.5">B</a></li>
     4424                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.10">A.5</a></li>
    44684425                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">3.1.1.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1.5</b></a>, <a href="#rfc.xref.header.content-type.3">8.3.1</a>, <a href="#rfc.xref.header.content-type.4">8.3.2</a></li>
    44694426               </ul>
    44704427            </li>
    44714428            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    4472                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">7.1</a>, <a href="#rfc.iref.d.3"><b>7.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">8.3.2</a>, <a href="#rfc.xref.header.date.4">C</a></li>
     4429                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">7.1</a>, <a href="#rfc.iref.d.3"><b>7.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">8.3.2</a></li>
    44734430                  <li>deflate (content coding)&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>3.1.2.1</b></a></li>
    44744431                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.2"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">8.1.3</a></li>
    … …  
    44764433            </li>
    44774434            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    4478                   <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.2</b></a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.xref.header.expect.3">8.3.2</a>, <a href="#rfc.xref.header.expect.4">C</a></li>
     4435                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.2</b></a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.xref.header.expect.3">8.3.2</a>, <a href="#rfc.xref.header.expect.4">B</a></li>
    44794436                  <li>Expect Values&nbsp;&nbsp;
    44804437                     <ul>
    … …  
    44894446            </li>
    44904447            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4491                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">C</a></li>
     4448                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
    44924449                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    44934450                     <ul>
    … …  
    45314488                        <li><tt>media-type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.1.1</b></a></li>
    45324489                        <li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>4.1</b></a></li>
    4533                         <li><tt>MIME-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>A.1</b></a></li>
    45344490                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>7.1.1.1</b></a></li>
    45354491                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>7.1.1.1</b></a></li>
    … …  
    45664522            </li>
    45674523            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    4568                   <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">C</a></li>
     4524                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">B</a></li>
    45694525               </ul>
    45704526            </li>
    45714527            <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
    4572                   <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>
     4528                  <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">B</a></li>
    45734529                  <li>MIME-Version header field&nbsp;&nbsp;<a href="#rfc.xref.mime-version.1">8.3.2</a>, <a href="#rfc.iref.m.2"><b>A.1</b></a></li>
    45744530               </ul>
    45754531            </li>
    45764532            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    4577                   <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.1</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.13">C</a>, <a href="#rfc.xref.OPTIONS.4">C</a></li>
     4533                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.1</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.13">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.14">B</a></li>
    45784534               </ul>
    45794535            </li>
    45804536            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4581                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">C</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul>
     4537                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a><ul>
    45824538                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    45834539                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    45844540                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.6.6</a></li>
    4585                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a></li>
    4586                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.53">D</a></li>
    4587                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a></li>
    4588                         <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a></li>
     4541                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.54">C</a></li>
     4542                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.53">C</a></li>
     4543                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a></li>
     4544                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a></li>
    45894545                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li>
    45904546                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.1.2</a></li>
    … …  
    46004556                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
    46014557                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li>
    4602                         <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.45">C</a></li>
     4558                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.4</a></li>
    46034559                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.3.4</a></li>
    46044560                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li>
    … …  
    46214577                     </ul>
    46224578                  </li>
    4623                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="#rfc.xref.Part5.12">8.1.2</a>, <a href="#Part5"><b>11.1</b></a><ul>
     4579                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="#rfc.xref.Part5.12">8.1.2</a>, <a href="#Part5"><b>11.1</b></a>, <a href="#rfc.xref.Part5.13">A.6</a><ul>
    46244580                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
    46254581                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
    … …  
    46294585                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">5.2</a></li>
    46304586                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.6">5.1</a></li>
     4587                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.13">A.6</a></li>
    46314588                     </ul>
    46324589                  </li>
    … …  
    46534610                  </li>
    46544611                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li>
    4655                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">8.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li>
    4656                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">8.1.3</a>, <a href="#rfc.xref.PUT.4">C</a>, <a href="#rfc.xref.PUT.5">C</a></li>
     4612                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">8.1.3</a></li>
     4613                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">8.1.3</a>, <a href="#rfc.xref.PUT.4">B</a></li>
    46574614               </ul>
    46584615            </li>
    46594616            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    4660                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.3</a>, <a href="#rfc.xref.header.referer.4">C</a></li>
     4617                  <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.3</a>, <a href="#rfc.xref.header.referer.4">B</a></li>
    46614618                  <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">3</a></li>
    46624619                  <li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li>
    46634620                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3.2</a></li>
    46644621                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">7.1.1.1</a>, <a href="#RFC1305"><b>11.2</b></a></li>
    4665                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a><ul>
     4622                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a><ul>
    46664623                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a></li>
    46674624                     </ul>
    … …  
    46704627                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">8.4.2</a>, <a href="#RFC1951"><b>11.1</b></a></li>
    46714628                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">8.4.2</a>, <a href="#RFC1952"><b>11.1</b></a></li>
    4672                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li>
     4629                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">3.1.1.3</a>, <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.2">A</a>, <a href="#rfc.xref.RFC2045.3">A.1</a></li>
    46734630                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.1.1.1</a>, <a href="#rfc.xref.RFC2046.2">3.1.1.4</a>, <a href="#rfc.xref.RFC2046.3">3.1.1.5</a>, <a href="#RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
    46744631                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">3.1.1.5</a></li>
    … …  
    46764633                     </ul>
    46774634                  </li>
    4678                   <li><em>RFC2049</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">3.1.1.3</a>, <a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.2">A.2</a><ul>
    4679                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.2">A.2</a></li>
     4635                  <li><em>RFC2049</em>&nbsp;&nbsp;<a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul>
     4636                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">A.2</a></li>
    46804637                     </ul>
    46814638                  </li>
    4682                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.2.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#rfc.xref.RFC2068.3">6.4</a>, <a href="#RFC2068"><b>11.2</b></a>, <a href="#rfc.xref.RFC2068.4">B</a><ul>
     4639                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.2.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#rfc.xref.RFC2068.3">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul>
    46834640                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.4</a></li>
    46844641                        <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li>
    46854642                     </ul>
    46864643                  </li>
    4687                   <li><em>RFC2076</em>&nbsp;&nbsp;<a href="#RFC2076"><b>11.2</b></a>, <a href="#rfc.xref.RFC2076.1">B</a></li>
    46884644                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>11.1</b></a></li>
    46894645                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.4</a>, <a href="#RFC2295"><b>11.2</b></a></li>
    … …  
    46984654                     </ul>
    46994655                  </li>
    4700                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">C</a>, <a href="#rfc.xref.RFC2817.3">C</a>, <a href="#rfc.xref.RFC2817.4">C</a><ul>
    4701                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.4">C</a></li>
     4656                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">B</a>, <a href="#rfc.xref.RFC2817.3">B</a>, <a href="#rfc.xref.RFC2817.4">B</a><ul>
     4657                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.4">B</a></li>
    47024658                     </ul>
    47034659                  </li>
    … …  
    47194675                     </ul>
    47204676                  </li>
    4721                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">8.3.1</a>, <a href="#RFC5234"><b>11.1</b></a>, <a href="#rfc.xref.RFC5234.3">D</a><ul>
    4722                         <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.3">D</a></li>
     4677                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">8.3.1</a>, <a href="#RFC5234"><b>11.1</b></a>, <a href="#rfc.xref.RFC5234.3">C</a><ul>
     4678                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.3">C</a></li>
    47234679                     </ul>
    47244680                  </li>
    … …  
    47354691                  <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">4.3.4</a>, <a href="#RFC5789"><b>11.2</b></a></li>
    47364692                  <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">8.3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li>
    4737                   <li><em>RFC6151</em>&nbsp;&nbsp;<a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li>
    47384693                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">4.3.8</a>, <a href="#RFC6265"><b>11.2</b></a></li>
    4739                   <li><em>RFC6266</em>&nbsp;&nbsp;<a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">B</a>, <a href="#rfc.xref.RFC6266.2">C</a></li>
     4694                  <li><em>RFC6266</em>&nbsp;&nbsp;<a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">B</a></li>
    47404695                  <li><em>RFC6365</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6365.1">1.2</a>, <a href="#rfc.xref.RFC6365.2">3.1.1.2</a>, <a href="#RFC6365"><b>11.1</b></a></li>
    47414696               </ul>
    … …  
    47444699                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>4.2.1</b></a></li>
    47454700                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>7.2</b></a></li>
    4746                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.4</a>, <a href="#rfc.xref.header.server.4">C</a></li>
     4701                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.4</a></li>
    47474702                  <li>Status Codes Classes&nbsp;&nbsp;
    47484703                     <ul>
    47494704                        <li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>6.2</b></a></li>
    47504705                        <li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.3</b></a></li>
    4751                         <li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a>, <a href="#rfc.xref.status.3xx.2">C</a></li>
     4706                        <li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a>, <a href="#rfc.xref.status.3xx.2">B</a></li>
    47524707                        <li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.5</b></a></li>
    47534708                        <li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.6</b></a></li>
    … …  
    47584713            </li>
    47594714            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    4760                   <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">C</a>, <a href="#rfc.xref.TRACE.4">C</a></li>
     4715                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li>
    47614716               </ul>
    47624717            </li>

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

    r2082 r2083  
    408408   interoperable among systems with varying native encoding formats.
    409409   Representations selected or transferred via HTTP ought to be in canonical
    410    form, for many of the same reasons described by MIME
    411    <xref target="RFC2049"/>.
     410   form, for many of the same reasons described by the Multipurpose Internet
     411   Mail Extensions (MIME) <xref target="RFC2045"/>.
    412412   However, the performance characteristics of email deployments (i.e., store
    413413   and forward messages to peers) are significantly different from those
    … …  
    52775277</reference>
    52785278
    5279 <reference anchor="RFC2076">
    5280   <front>
    5281     <title abbrev="Internet Message Headers">Common Internet Message Headers</title>
    5282     <author initials="J." surname="Palme" fullname="Jacob Palme">
    5283       <organization>Stockholm University/KTH</organization>
    5284       <address><email>jpalme@dsv.su.se</email></address>
    5285     </author>
    5286     <date month="February" year="1997"/>
    5287   </front>
    5288   <seriesInfo name="RFC" value="2076"/>
    5289 </reference>
    5290 
    52915279<reference anchor='RFC2295'>
    52925280  <front>
    … …  
    55105498</reference>
    55115499
    5512 <reference anchor="RFC6151">
    5513   <front>
    5514     <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
    5515     <author initials="S." surname="Turner" fullname="S. Turner"/>
    5516     <author initials="L." surname="Chen" fullname="L. Chen"/>
    5517     <date year="2011" month="March" />
    5518   </front>
    5519   <seriesInfo name="RFC" value="6151" />
    5520 </reference>
    5521 
    55225500<reference anchor="RFC6265">
    55235501  <front>
    … …  
    55675545<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
    55685546<t>
    5569    HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
     5547   HTTP/1.1 uses many of the constructs defined for the
     5548   Internet Message Format <xref target="RFC5322"/> and the Multipurpose
     5549   Internet Mail Extensions (MIME) <xref target="RFC2045"/> to
    55705550   allow a message body to be transmitted in an open variety of
    5571    representations and with extensible mechanisms. However, RFC 2045
    5572    discusses mail, and HTTP has a few features that are different from
    5573    those described in MIME. These differences were carefully chosen
    5574    to optimize performance over binary connections, to allow greater
    5575    freedom in the use of new media types, to make date comparisons
    5576    easier, and to acknowledge the practice of some early HTTP servers
    5577    and clients.
     5551   representations and with extensible header fields. However, RFC 2045
     5552   is focused only on email; applications of HTTP have many characteristics
     5553   that differ from email, and hence HTTP has features that differ from MIME.
     5554   These differences were carefully chosen to optimize performance over binary
     5555   connections, to allow greater freedom in the use of new media types, to
     5556   make date comparisons easier, and to acknowledge the practice of some early
     5557   HTTP servers and clients.
    55785558</t>
    55795559<t>
    55805560   This appendix describes specific areas where HTTP differs from MIME.
    5581    Proxies and gateways to strict MIME environments &SHOULD; be
     5561   Proxies and gateways to and from strict MIME environments need to be
    55825562   aware of these differences and provide the appropriate conversions
    5583    where necessary. Proxies and gateways from MIME environments to HTTP
    5584    also need to be aware of the differences because some conversions
    5585    might be required.
     5563   where necessary.
    55865564</t>
    55875565
    … …  
    55905568  <x:anchor-alias value="MIME-Version"/>
    55915569<t>
    5592    HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
     5570   HTTP is not a MIME-compliant protocol. However, messages can
    55935571   include a single MIME-Version header field to indicate what
    55945572   version of the MIME protocol was used to construct the message. Use
    55955573   of the MIME-Version header field indicates that the message is in
    55965574   full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>).
    5597    Proxies/gateways are responsible for ensuring full conformance (where
     5575   Senders are responsible for ensuring full conformance (where
    55985576   possible) when exporting HTTP messages to strict MIME environments.
    55995577</t>
    5600 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="MIME-Version"/>
    5601   <x:ref>MIME-Version</x:ref> = 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
    5602 </artwork></figure>
    5603 <t>
    5604    MIME version "1.0" is the default for use in HTTP/1.1. However,
    5605    HTTP/1.1 message parsing and semantics are defined by this document
    5606    and not the MIME specification.
    5607 </t>
    56085578</section>
    56095579
    56105580<section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
    56115581<t>
    5612    MIME requires that an Internet mail body-part be converted to
    5613    canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
    5614    <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
    5615    allowed for subtypes of the "text" media type when transmitted over
    5616    HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
    5617    line breaks as CRLF and forbids the use of CR or LF outside of line
    5618    break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
    5619    line break within text content when a message is transmitted over
    5620    HTTP.
    5621 </t>
    5622 <t>
    5623    Where it is possible, a proxy or gateway from HTTP to a strict MIME
    5624    environment &SHOULD; translate all line breaks within the text media
     5582   MIME requires that an Internet mail body-part be converted to canonical
     5583   form prior to being transferred, as described in <xref target="RFC2049"
     5584   x:fmt="of" x:sec="4"/>. <xref target="canonicalization.and.text.defaults"/>
     5585   of this document describes the forms allowed for subtypes of the "text"
     5586   media type when transmitted over HTTP. <xref target="RFC2046"/> requires
     5587   that content with a type of "text" represent line breaks as CRLF and
     5588   forbids the use of CR or LF outside of line break sequences. HTTP allows
     5589   CRLF, bare CR, and bare LF to indicate a line break within text content.
     5590</t>
     5591<t>
     5592   A proxy or gateway from HTTP to a strict MIME
     5593   environment ought to translate all line breaks within the text media
    56255594   types described in <xref target="canonicalization.and.text.defaults"/>
    56265595   of this document to the RFC 2049 canonical form of CRLF. Note, however,
    … …  
    56425611   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
    56435612   simplify the process of date comparison. Proxies and gateways from
    5644    other protocols &SHOULD; ensure that any <x:ref>Date</x:ref> header field
     5613   other protocols ought to ensure that any <x:ref>Date</x:ref> header field
    56455614   present in a message conforms to one of the HTTP/1.1 formats and rewrite
    56465615   the date if necessary.
    … …  
    56485617</section>
    56495618
    5650 <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
     5619<section title="Conversion of Content-Encoding" anchor="conversion.content-encoding">
    56515620<t>
    56525621   MIME does not include any concept equivalent to HTTP/1.1's
    56535622   <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier
    56545623   on the media type, proxies and gateways from HTTP to MIME-compliant
    5655    protocols &MUST; either change the value of the <x:ref>Content-Type</x:ref>
     5624   protocols ought to either change the value of the <x:ref>Content-Type</x:ref>
    56565625   header field or decode the representation before forwarding the message.
    56575626   (Some experimental applications of Content-Type for Internet mail have used
    … …  
    56625631</section>
    56635632
    5664 <section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
     5633<section title="Conversion of Content-Transfer-Encoding" anchor="conversion.content-transfer-encoding">
    56655634  <iref item="Content-Transfer-Encoding header field" x:for-anchor=""/>
    56665635<t>
    56675636   HTTP does not use the Content-Transfer-Encoding field of MIME.
    5668    Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
    5669    remove any Content-Transfer-Encoding
    5670    prior to delivering the response message to an HTTP client.
     5637   Proxies and gateways from MIME-compliant protocols to HTTP need to remove
     5638   any Content-Transfer-Encoding prior to delivering the response message to
     5639   an HTTP client.
    56715640</t>
    56725641<t>
    … …  
    56755644   and encoding for safe transport on that protocol, where "safe
    56765645   transport" is defined by the limitations of the protocol being used.
    5677    Such a proxy or gateway &SHOULD; label the data with an appropriate
    5678    Content-Transfer-Encoding if doing so will improve the likelihood of
    5679    safe transport over the destination protocol.
     5646   Such a proxy or gateway ought to transform and label the data with an
     5647   appropriate Content-Transfer-Encoding if doing so will improve the
     5648   likelihood of safe transport over the destination protocol.
    56805649</t>
    56815650</section>
    … …  
    56835652<section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
    56845653<t>
    5685    HTTP implementations that share code with MHTML <xref target="RFC2557"/> implementations
    5686    need to be aware of MIME line length limitations. Since HTTP does not
    5687    have this limitation, HTTP does not fold long lines. MHTML messages
    5688    being transported by HTTP follow all conventions of MHTML, including
    5689    line length limitations and folding, canonicalization, etc., since
    5690    HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and
    5691    does not interpret the content or any MIME header lines that might be
    5692    contained therein.
    5693 </t>
    5694 </section>
    5695 </section>
    5696 
    5697 <section title="Additional Features" anchor="additional.features">
    5698 <t>
    5699    <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
    5700    existing HTTP implementations, but not consistently and correctly
    5701    across most HTTP/1.1 applications. Implementers are advised to be
    5702    aware of these features, but cannot rely upon their presence in, or
    5703    interoperability with, other HTTP/1.1 applications. Some of these
    5704    describe proposed experimental features, and some describe features
    5705    that experimental deployment found lacking that are now addressed in
    5706    the base HTTP/1.1 specification.
    5707 </t>
    5708 <t>
    5709    A number of other header fields, such as Content-Disposition and Title,
    5710    from SMTP and MIME are also often implemented (see <xref target="RFC6266"/>
    5711    and <xref target="RFC2076"/>).
    5712 </t>
    5713 </section>
    5714 
    5715 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    5716 <t>
    5717    Request semantics embedded in a URI should be disabled when those
    5718    semantics are inconsistent with the request method, since this is a
    5719    common cause of interoperability failure.
    5720 </t>
    5721 <t>
    5722   The term "representation" is introduced, replacing both "entity" and
    5723   "variant."
    5724   (<xref target="representations" />)
    5725 </t>
    5726 <t>
    5727   Rules for identifying the payload of a message have been defined.
    5728   (<xref target="identifying.payload" />)
    5729 </t>
    5730 <t>
    5731   "Server-Driven" and "agent-driven" content negotiation are now called
    5732   "proactive" and "reactive" content negotiation (respectively).
    5733   (<xref target="content.negotiation" />)
    5734 </t>
    5735 <t>
    5736   <x:ref>Content-Location</x:ref> no longer sets a base URI, due to poor
    5737   implementation support (which was caused by too many broken servers emitting
    5738   bogus Content-Location header fields, and also the potentially undesirable
    5739   effect of potentially breaking relative links in content-negotiated
    5740   resources).
    5741   (<xref target="header.content-location"/>)
    5742 </t>
    5743 <t>
    5744   GET requests can have a body; it just has no meaning.
    5745   (<xref target="GET"/>)
    5746 </t>
    5747 <t>
    5748   The definition of POST has been clarified.
    5749   (<xref target="POST"/>)
    5750 </t>
    5751 <t>
    5752   Servers are no longer required to handle all Content-* header fields in
    5753   requests.
    5754   (<xref target="PUT"/>)
    5755 </t>
    5756 <t>
    5757   Use of <x:ref>Content-Range</x:ref> is explicitly banned on PUT requests.
    5758   (<xref target="PUT"/>)
    5759 </t>
    5760 <t>
    5761   The CONNECT method is now defined by this specification, taking over from
    5762   <xref target="RFC2817"/>.
    5763   (<xref target="CONNECT"/>)
    5764 </t>
    5765 <t>
    5766   The requirements upon and semantics of CONNECT request and response bodies
    5767   have been clarified.
    5768   (<xref target="CONNECT"/>)
    5769 </t>
    5770 <t>
    5771   The <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> request methods are
    5772   now defined as being safe.
    5773   (<xref target="OPTIONS"/> and <xref target="TRACE"/>)
    5774 </t>
    5775 <t>
    5776   The <x:ref>Max-Forwards</x:ref> header field is now restricted to the
    5777   OPTIONS and TRACE methods (previously, extension methods could have used it
    5778   as well).
    5779   (<xref target="header.max-forwards"/>)
    5780 </t>
    5781 <t>
    5782   The ABNF for the "<x:ref>Expect</x:ref>" header field has been both fixed
    5783   (allowing parameters for value-less expectations as well) and simplified
    5784   (allowing trailing semicolons after "100-continue" when they were invalid
    5785   before).
    5786   (<xref target="header.expect"/>)
    5787 </t>
    5788 <t>
    5789   Special casing for ISO-8859-1 in <x:ref>Accept-Charset</x:ref> has been
    5790   removed.
    5791   (<xref target="header.accept-charset"/>)
    5792 </t>
    5793 <t>
    5794   Requirements for sending the Date header field have been clarified.
    5795   (<xref target="header.date"/>)
    5796 </t>
    5797 <t>
    5798   The <x:ref>Referer</x:ref> header field can now have a value of
    5799   "about:blank" as an alternative to not sending a Referer header field.
    5800   (<xref target="header.referer"/>)
    5801 </t>
    5802 <t>
    5803   The <x:ref>201 (Created)</x:ref> status code can indicate that more than
    5804   one resource has been created (as well as just one).
    5805 </t>
    5806 <t>
    5807   The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has
    5808   been broadened to include cases of payload transformations as well.
    5809   (<xref target="status.203"/>)
    5810 </t>
    5811 <t>
    5812   Redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and
    5813   <x:ref>307</x:ref> no longer have normative requirements on response
    5814   payloads and user interaction.
    5815   (<xref target="status.3xx"/>)
    5816 </t>
    5817 <t>
    5818   The request methods that are safe to automatically redirect is no
    5819   longer a closed set; user agents are able to make that determination
    5820   based upon the request method semantics.
    5821   (<xref target="status.3xx"/>)
    5822 </t>
    5823 <t>
    5824   The syntax of the <x:ref>Location</x:ref> header field has been corrected
    5825   to allow URI references (including relative references and fragments), along
    5826   with some clarifications as to when use of fragments would not be
    5827   appropriate.
    5828   (<xref target="header.location"/>)
    5829 </t>
    5830 <t>
    5831   The 303 (See Other) status code is now cacheable, if explicit freshness
    5832   information is available.
    5833   (<xref target="status.303" />)
    5834 </t>
    5835 <t>
    5836   User agents are now allowed to rewrite the method from POST to GET
    5837   for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>.
    5838   (Sections <xref format="counter" target="status.301"/>,
    5839   <xref format="counter" target="status.302"/> and
    5840   <xref format="counter" target="status.307"/>)
    5841 </t>
    5842 <t>
    5843   The <x:ref>305 (Use Proxy)</x:ref> status code is now deprecated, because
    5844   user agents did not implement it. It used to indicate that the target
    5845   resource needed to be accessed through the proxy given by the
    5846   <x:ref>Location</x:ref> field. The recipient was expected to repeat this
    5847   single request via the proxy.
    5848   (<xref target="status.305"/>)
    5849 </t>
    5850 <t>
    5851   The <x:ref>400 (Bad Request)</x:ref> status code has been made more generic;
    5852   it isn't limited to syntax errors.
    5853   (<xref target="status.400"/>)
    5854 </t>
    5855 <t>
    5856   The <x:ref>403 (Forbidden)</x:ref> status code has been clarified,
    5857   especially with regards to authentication.
    5858   (<xref target="status.403"/>)
    5859 </t>
    5860 <t>
    5861   The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated
    5862   from <xref target="RFC2817"/>.
    5863   (<xref target="status.426"/>)
    5864 </t>
    5865 <t>
    5866   <x:ref>Allow</x:ref> has been reclassified as a response header field,
    5867   removing the option to specify it in a PUT request.
    5868   (<xref target="header.allow"/>)
    5869 </t> 
    5870 <t> 
    5871   Requirements relating to the content of the Allow header have been relaxed;
    5872   correspondingly, clients are not required to always trust its value.
    5873   (<xref target="header.allow"/>)
    5874 </t>
    5875 <t>
    5876   The requirement to generate a <x:ref>Via</x:ref> header field has been moved
    5877   from the description of the <x:ref>Server</x:ref> header field to
    5878   &header-via;.
    5879   (<xref target="header.server"/>)
    5880 </t>
    5881 <t>
    5882   The contexts that charset is used in have been clarified.
    5883   (<xref target="charset"/>)
    5884 </t>
    5885 <t>
    5886   The default charset of "ISO-8859-1" for text media types has been removed;
    5887   the default now is whatever the media type definition says.
    5888   (<xref target="canonicalization.and.text.defaults"/>)
    5889 </t>
    5890 <t>
    5891   Registration of Content Codings now requires IETF Review.
    5892   (<xref target="content.coding.registry"/>)
    5893 </t>
    5894 <t>
    5895   The Content-MD5 header field has been removed, because it was inconsistently
    5896   implemented with respect to partial responses, and also because of known
    5897   deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for
    5898   details).
    5899 </t>
    5900 <t>
    5901   This specification introduces a Method Registry.
    5902   (<xref target="method.registry"/>)
    5903 </t>
    5904 <t>
    5905   The Status Code Registry is now defined by this specification; previously,
    5906   it was defined in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
    5907   (<xref target="status.code.registry"/>)
    5908 </t>
    5909 <t>
    5910   References to the "identity" transfer coding token have been removed.
    5911   (<xref target="no.content-transfer-encoding"/>)
    5912 </t>
    5913 <t>
    5914   The Content-Disposition header field is now defined by <xref
    5915   target="RFC6266"/>.
    5916   (<xref target="additional.features"/>)
     5654   HTTP implementations that share code with MHTML <xref target="RFC2557"/>
     5655   implementations need to be aware of MIME line length limitations.
     5656   Since HTTP does not have this limitation, HTTP does not fold long lines.
     5657   MHTML messages being transported by HTTP follow all conventions of MHTML,
     5658   including line length limitations and folding, canonicalization, etc.,
     5659   since HTTP transfers message-bodies as payload and, aside from the
     5660   "multipart/byteranges" type (&multipart-byteranges;), does not interpret
     5661   the content or any MIME header lines that might be contained therein.
     5662</t>
     5663</section>
     5664</section>
     5665
     5666<section title="Significant changes from RFC 2616" anchor="changes.from.rfc.2616">
     5667<t>
     5668   The primary changes in this revision have been editorial in nature:
     5669   extracting the messaging syntax and partitioning HTTP semantics into
     5670   separate documents for the core features, conditional requests, partial
     5671   requests, caching, and authentication.  The conformance language has been
     5672   revised to clearly target requirements and the terminology has been
     5673   improved to distinguish payload from representations and representations
     5674   from resources.
     5675   An algorithm has been added for determining if a payload is associated with
     5676   a specific identifier (<xref target="identifying.payload" />).
     5677</t>
     5678<t>
     5679   A new requirement has been added that semantics embedded in a URI
     5680   should be disabled when those semantics are inconsistent with the request
     5681   method, since this is a common cause of interoperability failure.
     5682</t>
     5683<t>
     5684   The default charset of ISO-8859-1 for text media types has been removed;
     5685   the default is now whatever the media type definition says
     5686   (<xref target="canonicalization.and.text.defaults"/>). Likewise,
     5687   special treatment of ISO-8859-1 has been removed from the
     5688   <x:ref>Accept-Charset</x:ref> header field
     5689   (<xref target="header.accept-charset"/>).
     5690</t>
     5691<t>
     5692   The Content-Disposition header field has been removed since it is now
     5693   defined by <xref target="RFC6266"/>.
     5694</t>
     5695<t>
     5696   The definition of <x:ref>Content-Location</x:ref> has been changed to no
     5697   longer affect the base URI for resolving relative URI references, due to
     5698   poor implementation support and the undesirable effect of potentially
     5699   breaking relative links in content-negotiated resources
     5700   (<xref target="header.content-location"/>).
     5701</t>
     5702<t>
     5703   The Content-MD5 header field has been removed because it was inconsistently
     5704   implemented with respect to partial responses.
     5705</t>
     5706<t>
     5707   To be consistent with the method-neutral parsing algorithm of
     5708   <xref target="Part1"/>, the definition of GET has been relaxed so that
     5709   requests can have a body, even though a body has no meaning for GET
     5710   (<xref target="GET"/>).
     5711</t>
     5712<t>
     5713   Servers are no longer required to handle all Content-* header fields and
     5714   use of <x:ref>Content-Range</x:ref> has been explicitly banned in PUT
     5715   requests (<xref target="PUT"/>).
     5716</t>
     5717<t>
     5718   Definition of the CONNECT method has been moved from
     5719   <xref target="RFC2817"/> to this specification (<xref target="CONNECT"/>).
     5720</t>
     5721<t>
     5722   The <x:ref>OPTIONS</x:ref> (<xref target="OPTIONS"/>) and
     5723   <x:ref>TRACE</x:ref> (<xref target="TRACE"/>) request methods have been
     5724   defined as being safe.
     5725</t>
     5726<t>
     5727   The definition of <x:ref>Expect</x:ref> has been both fixed to allow
     5728   parameters for value-less expectations and simplified to allow trailing
     5729   semicolons after "100-continue" (<xref target="header.expect"/>).
     5730</t>
     5731<t>
     5732   The <x:ref>Max-Forwards</x:ref> header field
     5733   (<xref target="header.max-forwards"/>) has been restricted to the
     5734   <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> methods; previously,
     5735   extension methods could have used it as well.
     5736</t>
     5737<t>
     5738   The "about:blank" URI has been suggested as a value for the
     5739   <x:ref>Referer</x:ref> header field when no referring URI is applicable,
     5740   which distinguishes that case from others where the Referer field is
     5741   not sent or has been removed (<xref target="header.referer"/>).
     5742</t>
     5743<t>
     5744   The <x:ref>201 (Created)</x:ref> status description has been changed to
     5745   allow for the possibility that more than one resource has been created
     5746   (<xref target="status.201"/>).
     5747</t>
     5748<t>
     5749   The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has
     5750   been broadened to include cases of payload transformations as well
     5751   (<xref target="status.203"/>).
     5752</t>
     5753<t>
     5754   The redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and
     5755   <x:ref>307</x:ref> no longer have normative requirements on response
     5756   payloads and user interaction (<xref target="status.3xx"/>).
     5757</t>
     5758<t>
     5759   The request methods that are safe to automatically redirect is no
     5760   longer a closed set; user agents are able to make that determination
     5761   based upon the request method semantics (<xref target="status.3xx"/>).
     5762</t>
     5763<t>
     5764   The description of 303 (See Other) status code has been changed to allow
     5765   it to be cached if explicit freshness information is given, and a specific
     5766   definition has been added for a 303 response to GET
     5767   (<xref target="status.303"/>).
     5768</t>
     5769<t>
     5770   The status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>
     5771   (sections <xref format="counter" target="status.301"/> and
     5772   <xref format="counter" target="status.302"/>) have been changed to allow
     5773   user agents to rewrite the method from POST to GET.
     5774</t>
     5775<t>
     5776   The <x:ref>305 (Use Proxy)</x:ref> status code has been deprecated due to
     5777   security concerns regarding in-band configuration of a proxy
     5778   (<xref target="status.305"/>).
     5779</t>
     5780<t>
     5781   The <x:ref>400 (Bad Request)</x:ref> status code has been relaxed so that
     5782   it isn't limited to syntax errors (<xref target="status.400"/>).
     5783</t>
     5784<t>
     5785   The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated
     5786   from <xref target="RFC2817"/> (<xref target="status.426"/>).
     5787</t>
     5788<t>
     5789   <x:ref>Allow</x:ref> has been reclassified as a response header field,
     5790   removing the option to specify it in a PUT request.
     5791   Requirements relating to the content of Allow have been relaxed;
     5792   correspondingly, clients are not required to always trust its value
     5793   (<xref target="header.allow"/>).
     5794</t>
     5795<t>
     5796   The target of requirements on HTTP-date and the Date header field have been
     5797   reduced to those systems generating the date, rather than all systems
     5798   sending a date (<xref target="origination.date"/>).
     5799</t>
     5800<t>
     5801   The syntax of the <x:ref>Location</x:ref> header field has been changed
     5802   to allow all URI references, including relative references and fragments,
     5803   along with some clarifications as to when use of fragments would not be
     5804   appropriate (<xref target="header.location"/>).
     5805</t>
     5806<t>
     5807   A Method Registry has been defined (<xref target="method.registry"/>).
     5808</t>
     5809<t>
     5810   The Status Code Registry (<xref target="status.code.registry"/>) has been
     5811   redefined by this specification; previously, it was defined in
     5812   <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
     5813</t>
     5814<t>
     5815   Registration of Content Codings has been changed to require IETF Review
     5816   (<xref target="content.coding.registry"/>).
    59175817</t>
    59185818</section>
    … …  
    60015901<x:ref>Location</x:ref> = URI-reference
    60025902
    6003 <x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT
    60045903<x:ref>Max-Forwards</x:ref> = 1*DIGIT
    60055904
Note: See TracChangeset for help on using the changeset viewer.