Ignore:
Timestamp:
Jan 29, 2012, 5:49:16 PM (8 years ago)
Author:
fielding@…
Message:

update generated HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1517 r1519  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 29, 2012";
     360       content: "Expires August 1, 2012";
    361361  }
    362362  @bottom-right {
     
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
     410      <meta name="dct.issued" scheme="ISO8601" content="2012-01-29">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: July 29, 2012</td>
     442               <td class="left">Expires: August 1, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
     
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">January 26, 2012</td>
     495               <td class="right">January 29, 2012</td>
    496496            </tr>
    497497         </tbody>
     
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on July 29, 2012.</p>
     528      <p>This Internet-Draft will expire on August 1, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    545545      <ul class="toc">
    546546         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    547                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    548                <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    549                      <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">ABNF Extension: #rule</a></li>
    550                      <li>1.2.2&nbsp;&nbsp;&nbsp;<a href="#basic.rules">Basic Rules</a></li>
    551                   </ul>
    552                </li>
     547               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirement Notation</a></li>
     548               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    553549            </ul>
    554550         </li>
    555551         <li>2.&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul>
    556552               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    557                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#message-orientation-and-buffering">Message Orientation and Buffering</a></li>
    558                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
    559                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    560                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     553               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
     554               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
     555               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     556               <li>2.5&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    561557               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
    562558               <li>2.7&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
     
    583579               </li>
    584580               <li>3.2&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul>
    585                      <li>3.2.1&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
    586                      <li>3.2.2&nbsp;&nbsp;&nbsp;<a href="#field.length">Field Length</a></li>
    587                      <li>3.2.3&nbsp;&nbsp;&nbsp;<a href="#field.rules">Common Field ABNF Rules</a></li>
     581                     <li>3.2.1&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li>
     582                     <li>3.2.2&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
     583                     <li>3.2.3&nbsp;&nbsp;&nbsp;<a href="#field.length">Field Length</a></li>
     584                     <li>3.2.4&nbsp;&nbsp;&nbsp;<a href="#field.components">Field value components</a></li>
     585                     <li>3.2.5&nbsp;&nbsp;&nbsp;<a href="#abnf.extension">ABNF list extension: #rule</a></li>
    588586                  </ul>
    589587               </li>
     
    753751         thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.
    754752      </p>
    755       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     753      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirement Notation</a></h2>
    756754      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    757755         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    758       </p>
    759       <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    760          Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section&nbsp;2</a> for definitions of these terms.
    761       </p>
    762       <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    763          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    764       </p>
    765       <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    766       </p>
    767       <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
    768          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    769          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    770          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    771          error recovery could lead to dangerous consequences.
    772756      </p>
    773757      <div id="rfc.iref.g.1"></div>
     
    784768      <div id="rfc.iref.g.12"></div>
    785769      <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>
    786       <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>.
     770      <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="#abnf.extension" title="ABNF list extension: #rule">Section&nbsp;3.2.5</a>. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF with the list rule expanded.
    787771      </p>
    788772      <div id="core.rules">
     
    792776         </p>
    793777      </div>
    794       <p id="rfc.section.1.2.p.3">As a syntactic convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical
    795          reasons.
    796       </p>
    797       <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">ABNF Extension: #rule</a></h3>
    798       <p id="rfc.section.1.2.1.p.1">The #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability.
    799       </p>
    800       <p id="rfc.section.1.2.1.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element"
    801          indicating at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single comma (",") and optional whitespace (OWS, <a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>).
    802       </p>
    803       <div id="rfc.figure.u.1"></div>
    804       <p>Thus,</p><pre class="text">  1#element =&gt; element *( OWS "," OWS element )
    805 </pre><div id="rfc.figure.u.2"></div>
    806       <p>and:</p><pre class="text">  #element =&gt; [ 1#element ]
    807 </pre><div id="rfc.figure.u.3"></div>
    808       <p>and for n &gt;= 1 and m &gt; 1:</p><pre class="text">  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
    809 </pre><p id="rfc.section.1.2.1.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions:
    810       </p>
    811       <div id="rfc.figure.u.4"></div><pre class="text">  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
    812  
    813   1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
    814 </pre><p id="rfc.section.1.2.1.p.8">Note that empty elements do not contribute to the count of elements present, though.</p>
    815       <p id="rfc.section.1.2.1.p.9">For example, given these ABNF productions:</p>
    816       <div id="rfc.figure.u.5"></div><pre class="text">  example-list      = 1#example-list-elmt
    817   example-list-elmt = token ; see <a href="#field.rules" title="Common Field ABNF Rules">Section&nbsp;3.2.3</a>
    818 </pre><p id="rfc.section.1.2.1.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p>
    819       <div id="rfc.figure.u.6"></div><pre class="text">  "foo,bar"
    820   "foo ,bar,"
    821   "foo , ,bar,charlie   "
    822 </pre><p id="rfc.section.1.2.1.p.13">But these values would be invalid, as at least one non-empty element is required:</p>
    823       <div id="rfc.figure.u.7"></div><pre class="text">  ""
    824   ","
    825   ",   ,"
    826 </pre><p id="rfc.section.1.2.1.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF, with the list rules expanded as explained above.
    827       </p>
    828       <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h3>
    829       <div id="rule.LWS">
    830          <p id="rfc.section.1.2.2.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
    831             and BWS ("bad" whitespace).
    832          </p>
    833       </div>
    834       <div id="rule.OWS">
    835          <p id="rfc.section.1.2.2.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting
    836             the field value or forwarding the message downstream.
    837          </p>
    838       </div>
    839       <div id="rule.RWS">
    840          <p id="rfc.section.1.2.2.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the
    841             message downstream.
    842          </p>
    843       </div>
    844       <div id="rule.BWS">
    845          <p id="rfc.section.1.2.2.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
    846          </p>
    847       </div>
    848       <div id="rule.whitespace">
    849          <p id="rfc.section.1.2.2.p.5">        </p>
    850       </div>
    851       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold )
    852                  ; "optional" whitespace
    853   <a href="#rule.whitespace" class="smpl">RWS</a>            = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold )
    854                  ; "required" whitespace
    855   <a href="#rule.whitespace" class="smpl">BWS</a>            = <a href="#rule.whitespace" class="smpl">OWS</a>
    856                  ; "bad" whitespace
    857   <a href="#rule.whitespace" class="smpl">obs-fold</a>       = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
    858                  ; obsolete line folding
    859                  ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.1</a>
    860 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">Architecture</a></h1>
     778      <p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p>
     779      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">Architecture</a></h1>
    861780      <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide
    862781         hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.
     
    889808         the origin server (O).
    890809      </p>
    891       <div id="rfc.figure.u.9"></div><pre class="drawing">         request   &gt;
     810      <div id="rfc.figure.u.1"></div><pre class="drawing">         request   &gt;
    892811    UA ======================================= O
    893812                                &lt;   response
     
    904823      </p>
    905824      <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
    906       <div id="rfc.figure.u.10"></div>
     825      <div id="rfc.figure.u.2"></div>
    907826      <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    908827User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
     
    910829Accept: */*
    911830
    912 </pre><div id="rfc.figure.u.11"></div>
     831</pre><div id="rfc.figure.u.3"></div>
    913832      <p>server response:</p><pre class="text">HTTP/1.1 200 OK
    914833Date: Mon, 27 Jul 2009 12:28:53 GMT
     
    922841
    923842<span id="exbody">Hello World!
    924 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2>
    925       <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations
    926          only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some
    927          amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide
    928          other services.
    929       </p>
    930       <p id="rfc.section.2.2.p.2">Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will
    931          not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood
    932          that behaviors can differ across connections, and between requests and responses.
    933       </p>
    934       <p id="rfc.section.2.2.p.3">Recipients <em class="bcp14">MUST</em> consider every message in a connection in isolation; because HTTP is a stateless protocol, it cannot be assumed that two requests
    935          on the same connection are from the same client or share any other common attributes. In particular, intermediaries might
    936          mix requests from different clients into a single server connection. Note that some existing HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) violate this requirement, thereby potentially causing interoperability and security problems.
    937       </p>
    938       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2>
    939       <p id="rfc.section.2.3.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
     843</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2>
     844      <p id="rfc.section.2.2.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
    940845         transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request
    941846         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
    942847      </p>
    943       <p id="rfc.section.2.3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's
     848      <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's
    944849         URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
    945850         a proxy via some other connection port or protocol instead of using the defaults.
    946851      </p>
    947       <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>.
     852      <p id="rfc.section.2.2.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>.
    948853      </p>
    949854      <div id="rfc.iref.i.1"></div>
    950       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    951       <p id="rfc.section.2.4.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
     855      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
     856      <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
    952857         HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel,
    953858         switching behavior based on the nature of each request.
    954859      </p>
    955       <div id="rfc.figure.u.12"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
     860      <div id="rfc.figure.u.4"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
    956861    <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b>
    957862               &lt;             &lt;             &lt;             &lt;
    958 </pre><p id="rfc.section.2.4.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
     863</pre><p id="rfc.section.2.3.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    959864         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    960865         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along
     
    963868         at the same time that it is handling A's request.
    964869      </p>
    965       <p id="rfc.section.2.4.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.
     870      <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.
    966871         Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
    967872      </p>
    968       <p id="rfc.section.2.4.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
     873      <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
    969874         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    970875         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
     
    972877         for the sake of security, annotation services, or shared caching.
    973878      </p>
    974       <p id="rfc.section.2.4.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,
     879      <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,
    975880         beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original
    976881         sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared
     
    980885         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    981886      </p>
    982       <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.16"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
     887      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
    983888         server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance
    984889         through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines.
    985890      </p>
    986       <p id="rfc.section.2.4.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
     891      <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
    987892         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    988893         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    989894         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
    990895      </p>
    991       <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
     896      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    992897         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    993898         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    994899         when transport-layer security is used to establish private communication through a shared firewall proxy.
    995900      </p>
    996       <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
     901      <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
    997902         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a
    998903         mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects
     
    1002907         from a man-in-the-middle attack.
    1003908      </p>
     909      <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
     910         depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple
     911         servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
     912         to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems.
     913      </p>
    1004914      <div id="rfc.iref.c.4"></div>
    1005       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    1006       <p id="rfc.section.2.5.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
     915      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
     916      <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
    1007917         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    1008918         requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
    1009919      </p>
    1010       <p id="rfc.section.2.5.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
     920      <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
    1011921         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    1012922         from O (via C) for a request which has not been cached by UA or A.
    1013923      </p>
    1014       <div id="rfc.figure.u.13"></div><pre class="drawing">            &gt;             &gt;
     924      <div id="rfc.figure.u.5"></div><pre class="drawing">            &gt;             &gt;
    1015925       UA =========== A =========== B - - - - - - C - - - - - - O
    1016926                  &lt;             &lt;
    1017 </pre><p id="rfc.section.2.5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
     927</pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
    1018928         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    1019929         can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    1020930      </p>
    1021       <p id="rfc.section.2.5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
     931      <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    1022932         inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems
    1023933         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so
    1024934         on.
     935      </p>
     936      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     937      <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     938         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     939         or caches, depending on what behavior is being constrained by the requirement.
     940      </p>
     941      <p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     942         in HTTP.
     943      </p>
     944      <p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements.
     945      </p>
     946      <p id="rfc.section.2.5.p.4">Unless otherwise noted, recipients <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
     947         except when they have a direct impact on security, since different applications of the protocol require different error handling
     948         strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field
     949         doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.
    1025950      </p>
    1026951      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
     
    1030955      </p>
    1031956      <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    1032       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
     957      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
    1033958  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    1034959</pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
     
    10891014         "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment.
    10901015      </p>
    1091       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
     1016      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
    10921017  <a href="#uri" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>&gt;
    10931018  <a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>&gt;
     
    11111036         namespace governed by a potential HTTP origin server listening for TCP connections on a given port.
    11121037      </p>
    1113       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1038      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11141039</pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an
    11151040         identifier for a potential resource within that origin server's name space.
     
    11501075         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request.
    11511076      </p>
    1152       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1077      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11531078</pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP
    11541079         or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     
    11711096      </p>
    11721097      <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p>
    1173       <div id="rfc.figure.u.18"></div><pre class="text">   http://example.com:80/~smith/home.html
     1098      <div id="rfc.figure.u.10"></div><pre class="text">   http://example.com:80/~smith/home.html
    11741099   http://EXAMPLE.com/%7Esmith/home.html
    11751100   http://EXAMPLE.com:/%7esmith/home.html
     
    11821107         the end of the header section, and an optional message-body.
    11831108      </p>
    1184       <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
     1109      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
    11851110                    *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    11861111                    <a href="#core.rules" class="smpl">CRLF</a>
     
    11961121         the message, such as within a header field-value after message parsing has delineated the individual fields.
    11971122      </p>
     1123      <p id="rfc.section.3.p.5">An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot
     1124         rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the
     1125         sake of network efficiency, security checks, or payload transformations.
     1126      </p>
    11981127      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="start.line" href="#start.line">Start Line</a></h2>
    11991128      <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
     
    12031132         or invalid request method) and clients are implemented to only expect a response.
    12041133      </p>
    1205       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request.line" class="smpl">Request-Line</a> / <a href="#status.line" class="smpl">Status-Line</a>
     1134      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request.line" class="smpl">Request-Line</a> / <a href="#status.line" class="smpl">Status-Line</a>
    12061135</pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
    12071136         attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
     
    12131142         the protocol version, and ending with CRLF.
    12141143      </p>
    1215       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#request.line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
     1144      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#request.line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
    12161145</pre><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h4>
    12171146      <p id="rfc.section.3.1.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    1218       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     1147      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    12191148</pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
    12201149         for new methods.
     
    12241153         described in <a href="#request-target-types" title="Types of Request Target">Section&nbsp;4.1</a>.
    12251154      </p>
    1226       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
     1155      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    12271156                 / <a href="#uri" class="smpl">absolute-URI</a>
    12281157                 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
     
    12411170         another space, a possibly-empty textual phrase describing the status code, and ending with CRLF.
    12421171      </p>
    1243       <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
     1172      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    12441173</pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a>&nbsp;<a id="status.code" href="#status.code">Status Code</a></h4>
    12451174      <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
    12461175         for new status codes.
    12471176      </p>
    1248       <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#status.code" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
     1177      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#status.code" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    12491178</pre><h4 id="rfc.section.3.1.2.2"><a href="#rfc.section.3.1.2.2">3.1.2.2</a>&nbsp;<a id="reason.phrase" href="#reason.phrase">Reason Phrase</a></h4>
    12501179      <p id="rfc.section.3.1.2.2.p.1">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     
    12521181         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
    12531182      </p>
    1254       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#reason.phrase" class="smpl">Reason-Phrase</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1183      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#reason.phrase" class="smpl">Reason-Phrase</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12551184</pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
    12561185      <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field
    12571186         value.
    12581187      </p>
    1259       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a>
     1188      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#header.fields" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a>
    12601189  <a href="#header.fields" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
    12611190  <a href="#header.fields" class="smpl">field-value</a>    = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">obs-fold</a> )
     
    12881217         </p>
    12891218      </div>
    1290       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>
    1291       <p id="rfc.section.3.2.1.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
     1219      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="whitespace" href="#whitespace">Whitespace</a></h3>
     1220      <div id="rule.LWS">
     1221         <p id="rfc.section.3.2.1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
     1222            and BWS ("bad" whitespace).
     1223         </p>
     1224      </div>
     1225      <div id="rule.OWS">
     1226         <p id="rfc.section.3.2.1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting
     1227            the field value or forwarding the message downstream.
     1228         </p>
     1229      </div>
     1230      <div id="rule.RWS">
     1231         <p id="rfc.section.3.2.1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the
     1232            message downstream.
     1233         </p>
     1234      </div>
     1235      <div id="rule.BWS">
     1236         <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
     1237         </p>
     1238      </div>
     1239      <div id="rule.whitespace">
     1240         <p id="rfc.section.3.2.1.p.5">        </p>
     1241      </div>
     1242      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.fields" class="smpl">OWS</a>            = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold )
     1243                 ; "optional" whitespace
     1244  <a href="#rule.whitespace" class="smpl">RWS</a>            = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold )
     1245                 ; "required" whitespace
     1246  <a href="#rule.whitespace" class="smpl">BWS</a>            = <a href="#header.fields" class="smpl">OWS</a>
     1247                 ; "bad" whitespace
     1248  <a href="#rule.whitespace" class="smpl">obs-fold</a>       = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
     1249                 ; obsolete line folding
     1250                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
     1251</pre><h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>
     1252      <p id="rfc.section.3.2.2.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
    12921253         have led to security vulnerabilities in request routing and response handling. Any received request message that contains
    12931254         whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
    12941255      </p>
    1295       <p id="rfc.section.3.2.1.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing
     1256      <p id="rfc.section.3.2.2.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing
    12961257         white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet
    12971258         of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field).
    12981259      </p>
    1299       <p id="rfc.section.3.2.1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
     1260      <p id="rfc.section.3.2.2.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    13001261         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    13011262         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the
     
    13031264         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
    13041265      </p>
    1305       <p id="rfc.section.3.2.1.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data.
    1306       </p>
    1307       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.length" href="#field.length">Field Length</a></h3>
    1308       <p id="rfc.section.3.2.2.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header
     1266      <p id="rfc.section.3.2.2.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data.
     1267      </p>
     1268      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="field.length" href="#field.length">Field Length</a></h3>
     1269      <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header
    13091270         field(s) would be longer than the server wishes to handle.
    13101271      </p>
    1311       <p id="rfc.section.3.2.2.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>
    1312       <p id="rfc.section.3.2.2.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
    1313       </p>
    1314       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="field.rules" href="#field.rules">Common Field ABNF Rules</a></h3>
     1272      <p id="rfc.section.3.2.3.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>
     1273      <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
     1274      </p>
     1275      <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
    13151276      <div id="rule.token.separators">
    1316          <p id="rfc.section.3.2.3.p.1">        Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.
     1277         <p id="rfc.section.3.2.4.p.1">        Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.
    13171278            These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
    13181279         </p>
    13191280      </div>
    1320       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span>  <a href="#rule.token.separators" class="smpl">word</a>           = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
     1281      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span>  <a href="#rule.token.separators" class="smpl">word</a>           = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
    13211282
    13221283  <a href="#rule.token.separators" class="smpl">token</a>          = 1*<a href="#rule.token.separators" class="smpl">tchar</a>
     
    13311292                 / "]" / "?" / "=" / "{" / "}"
    13321293</pre><div id="rule.quoted-string">
    1333          <p id="rfc.section.3.2.3.p.3">      A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
     1294         <p id="rfc.section.3.2.4.p.3">      A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
    13341295      </div>
    1335       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
    1336   <a href="#rule.quoted-string" class="smpl">qdtext</a>         = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
     1296      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
     1297  <a href="#rule.quoted-string" class="smpl">qdtext</a>         = <a href="#header.fields" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    13371298  <a href="#rule.quoted-string" class="smpl">obs-text</a>       = %x80-FF
    13381299</pre><div id="rule.quoted-pair">
    1339          <p id="rfc.section.3.2.3.p.5">  The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>
     1300         <p id="rfc.section.3.2.4.p.5">  The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>
    13401301      </div>
    1341       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-pair</a>    = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    1342 </pre><p id="rfc.section.3.2.3.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
    1343       </p>
    1344       <p id="rfc.section.3.2.3.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet).
     1302      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-pair</a>    = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1303</pre><p id="rfc.section.3.2.4.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
     1304      </p>
     1305      <p id="rfc.section.3.2.4.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet).
    13451306      </p>
    13461307      <div id="rule.comment">
    1347          <p id="rfc.section.3.2.3.p.9">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
     1308         <p id="rfc.section.3.2.4.p.9">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    13481309            in fields containing "comment" as part of their field value definition.
    13491310         </p>
    13501311      </div>
    1351       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
    1352   <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
     1312      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
     1313  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#header.fields" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    13531314</pre><div id="rule.quoted-cpair">
    1354          <p id="rfc.section.3.2.3.p.11">  The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>
     1315         <p id="rfc.section.3.2.4.p.11">  The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>
    13551316      </div>
    1356       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>    = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    1357 </pre><p id="rfc.section.3.2.3.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
     1317      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>    = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1318</pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
    13581319         ")").
     1320      </p>
     1321      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h3>
     1322      <p id="rfc.section.3.2.5.p.1">A #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability in the definitions of some header field values.
     1323      </p>
     1324      <p id="rfc.section.3.2.5.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element"
     1325         indicating at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single comma (",") and optional whitespace (OWS).
     1326      </p>
     1327      <div id="rfc.figure.u.26"></div>
     1328      <p>Thus,</p><pre class="text">  1#element =&gt; element *( OWS "," OWS element )
     1329</pre><div id="rfc.figure.u.27"></div>
     1330      <p>and:</p><pre class="text">  #element =&gt; [ 1#element ]
     1331</pre><div id="rfc.figure.u.28"></div>
     1332      <p>and for n &gt;= 1 and m &gt; 1:</p><pre class="text">  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
     1333</pre><p id="rfc.section.3.2.5.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions:
     1334      </p>
     1335      <div id="rfc.figure.u.29"></div><pre class="text">  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
     1336 
     1337  1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
     1338</pre><p id="rfc.section.3.2.5.p.8">Note that empty elements do not contribute to the count of elements present, though.</p>
     1339      <p id="rfc.section.3.2.5.p.9">For example, given these ABNF productions:</p>
     1340      <div id="rfc.figure.u.30"></div><pre class="text">  example-list      = 1#example-list-elmt
     1341  example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>
     1342</pre><p id="rfc.section.3.2.5.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p>
     1343      <div id="rfc.figure.u.31"></div><pre class="text">  "foo,bar"
     1344  "foo ,bar,"
     1345  "foo , ,bar,charlie   "
     1346</pre><p id="rfc.section.3.2.5.p.13">But these values would be invalid, as at least one non-empty element is required:</p>
     1347      <div id="rfc.figure.u.32"></div><pre class="text">  ""
     1348  ","
     1349  ",   ,"
     1350</pre><p id="rfc.section.3.2.5.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF, with the list rules expanded as explained above.
    13591351      </p>
    13601352      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
     
    14801472      </p>
    14811473      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
    1482       <p id="rfc.section.4.1.p.1">The four options for request-target are dependent on the nature of the request.</p>
    1483       <div id="asterix-form">
    1484          <p id="rfc.section.4.1.p.2"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
     1474      <p id="rfc.section.4.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the
     1475         request is being made to a proxy.
     1476      </p>
     1477      <div id="origin-form">
     1478         <p id="rfc.section.4.1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a
     1479            resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified
     1480            as
     1481         </p>
     1482      </div>
     1483      <div id="rfc.figure.u.34"></div><pre>http://www.example.org/where?q=now
     1484</pre><p id="rfc.section.4.1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
     1485         lines:
     1486      </p>
     1487      <div id="rfc.figure.u.35"></div><pre class="text2">GET /where?q=now HTTP/1.1
     1488Host: www.example.org
     1489</pre><p id="rfc.section.4.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
     1490         If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
     1491      </p>
     1492      <p id="rfc.section.4.1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
     1493      </p>
     1494      <div id="absolute-URI-form">
     1495         <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
     1496            cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
     1497            loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1498            An example Request-Line would be:
     1499         </p>
     1500      </div>
     1501      <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1502</pre><p id="rfc.section.4.1.p.10">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
     1503      </p>
     1504      <p id="rfc.section.4.1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
     1505      </p>
     1506      <div id="authority-form">
     1507         <p id="rfc.section.4.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,
     1508         </p>
     1509      </div>
     1510      <div id="rfc.figure.u.37"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     1511</pre><div id="asterix-form">
     1512         <p id="rfc.section.4.1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
    14851513            process) rather than to a specific named resource at that server. For example,
    14861514         </p>
    14871515      </div>
    1488       <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1
    1489 </pre><div id="absolute-URI-form">
    1490          <p id="rfc.section.4.1.p.4"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
    1491             cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    1492             loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, and the numeric IP
    1493             address. An example Request-Line would be:
    1494          </p>
    1495       </div>
    1496       <div id="rfc.figure.u.35"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1497 </pre><p id="rfc.section.4.1.p.6">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    1498       </p>
    1499       <p id="rfc.section.4.1.p.7">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    1500       </p>
    1501       <div id="authority-form">
    1502          <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1503          </p>
    1504       </div>
    1505       <div id="origin-form">
    1506          <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
    1507             the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified
    1508             above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and
    1509             send the lines:
    1510          </p>
    1511       </div>
    1512       <div id="rfc.figure.u.36"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
    1513 Host: www.example.org
    1514 </pre><p id="rfc.section.4.1.p.11">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path;
    1515          if the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
    1516       </p>
    1517       <p id="rfc.section.4.1.p.12">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
     1516      <div id="rfc.figure.u.38"></div><pre class="text2">OPTIONS * HTTP/1.1
     1517</pre><p id="rfc.section.4.1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
    15181518         no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server.
    15191519      </p>
    1520       <div id="rfc.figure.u.37"></div>
     1520      <div id="rfc.figure.u.39"></div>
    15211521      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1522 </pre><div id="rfc.figure.u.38"></div>
     1522</pre><div id="rfc.figure.u.40"></div>
    15231523      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    15241524Host: www.example.org:8001
    15251525</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1526       <p id="rfc.section.4.1.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
    1527       </p>
    1528       <p id="rfc.section.4.1.p.16">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1526      <p id="rfc.section.4.1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    15291527         except as noted above to replace a null path-absolute with "/" or "*".
    15301528      </p>
    1531       <div class="note" id="rfc.section.4.1.p.17">
    1532          <p> <b>Note:</b> The "no rewrite" rule above prevents the proxy from changing the meaning of the request when the origin server is improperly
    1533             using a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have
    1534             been known to rewrite the request-target.
    1535          </p>
    1536       </div>
    15371529      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
    15381530      <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header
     
    15811573      </p>
    15821574      <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    1583       <div id="rfc.figure.u.39"></div>
     1575      <div id="rfc.figure.u.41"></div>
    15841576      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    15851577Host: www.example.org:8080
     
    15871579         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    15881580      </p>
    1589       <div id="rfc.figure.u.40"></div>
     1581      <div id="rfc.figure.u.42"></div>
    15901582      <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
    15911583Host: www.example.org
     
    16011593         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    16021594      </p>
    1603       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
     1595      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
    16041596                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.1.2.1</a>
    16051597                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.1.2.2</a>
    16061598                          / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.1.2.3</a>
    16071599                          / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    1608   <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
     1600  <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
    16091601</pre><div id="rule.parameter">
    16101602         <p id="rfc.section.5.1.p.3">      Parameters are in the form of attribute/value pairs.</p>
    16111603      </div>
    1612       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
     1604      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
    16131605  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    16141606  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
     
    16281620         for the recipient to verify that it has received the full message.
    16291621      </p>
    1630       <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1622      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    16311623                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    16321624                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
     
    16711663      </p>
    16721664      <p id="rfc.section.5.1.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1673       <div id="rfc.figure.u.44"></div><pre class="text">  length := 0
     1665      <div id="rfc.figure.u.46"></div><pre class="text">  length := 0
    16741666  read chunk-size, chunk-ext (if any) and CRLF
    16751667  while (chunk-size &gt; 0) {
     
    17431735         By convention, the products are listed in order of their significance for identifying the application.
    17441736      </p>
    1745       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
     1737      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    17461738  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    17471739</pre><p id="rfc.section.5.2.p.3">Examples:</p>
    1748       <div id="rfc.figure.u.46"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1740      <div id="rfc.figure.u.48"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    17491741  Server: Apache/0.8.4
    17501742</pre><p id="rfc.section.5.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
     
    17551747         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    17561748      </p>
    1757       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1749      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    17581750                 / ( "1" [ "." 0*3("0") ] )
    17591751</pre><div class="note" id="rfc.section.5.3.p.3">
     
    20562048      </p>
    20572049      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2058       <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2050      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    20592051  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    20602052</pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
     
    20792071         of the response. For example,
    20802072      </p>
    2081       <div id="rfc.figure.u.49"></div><pre class="text">  Connection: close
     2073      <div id="rfc.figure.u.51"></div><pre class="text">  Connection: close
    20822074</pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>) after the current request/response is complete.
    20832075      </p>
     
    20952087         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    20962088      </p>
    2097       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     2089      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    20982090</pre><p id="rfc.section.8.2.p.3">An example is</p>
    2099       <div id="rfc.figure.u.51"></div><pre class="text">  Content-Length: 3495
     2091      <div id="rfc.figure.u.53"></div><pre class="text">  Content-Length: 3495
    21002092</pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    21012093         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
     
    21122104         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line.
    21132105      </p>
    2114       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     2106      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    21152107</pre><p id="rfc.section.8.3.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
    21162108         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    21172109      </p>
    21182110      <p id="rfc.section.8.3.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    2119       <div id="rfc.figure.u.53"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2111      <div id="rfc.figure.u.55"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    21202112Host: www.example.org
    21212113</pre><p id="rfc.section.8.3.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
     
    21442136         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
    21452137      </p>
    2146       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     2138      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    21472139  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
    2148   <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    2149   <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
     2140  <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
     2141  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    21502142</pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    21512143         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    21522144      </p>
    21532145      <p id="rfc.section.8.4.p.5">Examples of its use are:</p>
    2154       <div id="rfc.figure.u.55"></div><pre class="text">  TE: deflate
     2146      <div id="rfc.figure.u.57"></div><pre class="text">  TE: deflate
    21552147  TE:
    21562148  TE: trailers, deflate;q=0.5
     
    21892181         chunked transfer-coding.
    21902182      </p>
    2191       <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     2183      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    21922184</pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    21932185         to know which header fields to expect in the trailer.
     
    22092201         are not.
    22102202      </p>
    2211       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
     2203      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    22122204</pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>. An example is:
    22132205      </p>
    2214       <div id="rfc.figure.u.58"></div><pre class="text">  Transfer-Encoding: chunked
     2206      <div id="rfc.figure.u.60"></div><pre class="text">  Transfer-Encoding: chunked
    22152207</pre><p id="rfc.section.8.6.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    22162208      </p>
     
    22222214         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    22232215      </p>
    2224       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
     2216      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    22252217</pre><p id="rfc.section.8.7.p.3">For example,</p>
    2226       <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2218      <div id="rfc.figure.u.62"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    22272219</pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    22282220         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
     
    22792271         of all senders along the request/response chain.
    22802272      </p>
    2281       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     2273      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    22822274                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    22832275  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a>
     
    23032295         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    23042296      </p>
    2305       <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2297      <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    23062298</pre><p id="rfc.section.8.8.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    23072299         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
     
    23102302         For example,
    23112303      </p>
    2312       <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2304      <div id="rfc.figure.u.65"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    23132305</pre><p id="rfc.section.8.8.p.12">could be collapsed to</p>
    2314       <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2306      <div id="rfc.figure.u.66"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    23152307</pre><p id="rfc.section.8.8.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    23162308         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     
    29562948      </p>
    29572949      <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>
    2958       <p id="rfc.section.A.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section&nbsp;1.2.1</a>)
    2959       </p>
    2960       <p id="rfc.section.A.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically
    2961          pointed out in the ABNF. (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
     2950      <p id="rfc.section.A.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section&nbsp;3.2.5</a>)
     2951      </p>
     2952      <p id="rfc.section.A.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed
     2953         where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section&nbsp;3.2.1</a>)
    29622954      </p>
    29632955      <p id="rfc.section.A.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single
     
    29682960      <p id="rfc.section.A.2.p.5">The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer allows escaping control
    29692961         characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted and made opaque (the TEXT
    2970          rule was removed). (<a href="#field.rules" title="Common Field ABNF Rules">Section&nbsp;3.2.3</a>)
     2962         rule was removed). (<a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>)
    29712963      </p>
    29722964      <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
     
    29922984      </p>
    29932985      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    2994       <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     2986      <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    29952987
    29962988<a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
     
    30072999<a href="#method" class="smpl">Method</a> = token
    30083000
    3009 <a href="#rule.whitespace" class="smpl">OWS</a> = *( SP / HTAB / obs-fold )
     3001<a href="#header.fields" class="smpl">OWS</a> = *( SP / HTAB / obs-fold )
    30103002
    30113003<a href="#rule.whitespace" class="smpl">RWS</a> = 1*( SP / HTAB / obs-fold )
     
    31103102
    31113103<a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string
    3112 </pre> <div id="rfc.figure.u.66"></div>
     3104</pre> <div id="rfc.figure.u.68"></div>
    31133105      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
    31143106; Connection defined but not used
     
    35063498         <ul class="ind">
    35073499            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3508                   <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1</a></li>
    3509                   <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.4</b></a></li>
     3500                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1</a></li>
     3501                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    35103502                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
    3511                   <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1</a></li>
    3512                   <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">4.1</a></li>
     3503                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">4.1</a></li>
     3504                  <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1</a></li>
    35133505               </ul>
    35143506            </li>
     
    35183510            </li>
    35193511            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3520                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.5</b></a></li>
    3521                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li>
    3522                   <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
     3512                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
     3513                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
     3514                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    35233515                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">5.1.1</a></li>
    35243516                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
     
    35333525                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1.2.1</a></li>
    35343526                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3535                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
     3527                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    35363528                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    35373529               </ul>
     
    35393531            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    35403532                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.1.2.2</a></li>
    3541                   <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
     3533                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    35423534               </ul>
    35433535            </li>
     
    35473539            </li>
    35483540            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3549                   <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.4</b></a></li>
     3541                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.3</b></a></li>
    35503542                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35513543                     <ul>
    3552                         <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
     3544                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    35533545                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    35543546                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5.1</b></a></li>
    3555                         <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    3556                         <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
     3547                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
     3548                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
    35573549                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5.1.1</b></a></li>
    35583550                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1.1</b></a></li>
     
    35623554                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1.1</b></a></li>
    35633555                        <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5.1.1</b></a></li>
    3564                         <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.3</b></a></li>
     3556                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    35653557                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>8.1</b></a></li>
    35663558                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>8.1</b></a></li>
     
    35683560                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    35693561                        <li>CRLF&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>1.2</b></a></li>
    3570                         <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.3</b></a></li>
     3562                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
    35713563                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    35723564                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5.1</b></a></li>
     
    35743566                        <li>DIGIT&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>1.2</b></a></li>
    35753567                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    3576                         <li><tt>field-content</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2</b></a></li>
    3577                         <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2</b></a></li>
    3578                         <li><tt>field-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2</b></a></li>
    3579                         <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a></li>
     3568                        <li><tt>field-content</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a></li>
     3569                        <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>3.2</b></a></li>
     3570                        <li><tt>field-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.2</b></a></li>
     3571                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.2</b></a></li>
    35803572                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    35813573                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>8.3</b></a></li>
    35823574                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    3583                         <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3</b></a></li>
    3584                         <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.6</b></a></li>
    3585                         <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>2.7.1</b></a></li>
    3586                         <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.6</b></a></li>
    3587                         <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.7.2</b></a></li>
     3575                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>3</b></a></li>
     3576                        <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.6</b></a></li>
     3577                        <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7.1</b></a></li>
     3578                        <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
     3579                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7.2</b></a></li>
    35883580                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1.1</b></a></li>
    35893581                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    35903582                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.3</b></a></li>
    3591                         <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.1.1</b></a></li>
    3592                         <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.3</b></a></li>
     3583                        <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3.1.1.1</b></a></li>
     3584                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    35933585                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
    3594                         <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>1.2.2</b></a></li>
    3595                         <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    3596                         <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
     3586                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
     3587                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
     3588                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    35973589                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.2</b></a></li>
    35983590                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.2</b></a></li>
     
    36003592                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.8</b></a></li>
    36013593                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.8</b></a></li>
    3602                         <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.3</b></a></li>
     3594                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    36033595                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.1.1</b></a></li>
    3604                         <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7</b></a></li>
    3605                         <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.3</b></a></li>
    3606                         <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.3</b></a></li>
     3596                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
     3597                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.4</b></a></li>
     3598                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.4</b></a></li>
    36073599                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.1.1</b></a></li>
    3608                         <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.3</b></a></li>
     3600                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.4</b></a></li>
    36093601                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.3</b></a></li>
    3610                         <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.1.2.2</b></a></li>
     3602                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li>
    36113603                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.8</b></a></li>
    36123604                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.8</b></a></li>
    3613                         <li><tt>Request-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.1</b></a></li>
    3614                         <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.1.2</b></a></li>
    3615                         <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
     3605                        <li><tt>Request-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1.1</b></a></li>
     3606                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li>
     3607                        <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
    36163608                        <li>SP&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>1.2</b></a></li>
    3617                         <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.3</b></a></li>
    3618                         <li><tt>start-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1</b></a></li>
    3619                         <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>3.1.2.1</b></a></li>
    3620                         <li><tt>Status-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.1.2</b></a></li>
     3609                        <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.4</b></a></li>
     3610                        <li><tt>start-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>3.1</b></a></li>
     3611                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li>
     3612                        <li><tt>Status-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.2</b></a></li>
    36213613                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>8.4</b></a></li>
    3622                         <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.3</b></a></li>
     3614                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.4</b></a></li>
    36233615                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>8.4</b></a></li>
    36243616                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.4</b></a></li>
    36253617                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.4</b></a></li>
    3626                         <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.3</b></a></li>
     3618                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
    36273619                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.5</b></a></li>
    36283620                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1.1</b></a></li>
     
    36323624                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5.1</b></a></li>
    36333625                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.7</b></a></li>
    3634                         <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.7</b></a></li>
    3635                         <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
     3626                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
     3627                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    36363628                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5.1</b></a></li>
    36373629                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    36383630                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.8</b></a></li>
    3639                         <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.3</b></a></li>
     3631                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.4</b></a></li>
    36403632                     </ul>
    36413633                  </li>
     
    36473639                  <li>Header Fields&nbsp;&nbsp;
    36483640                     <ul>
    3649                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
     3641                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    36503642                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    36513643                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     
    36543646                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    36553647                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3656                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3648                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    36573649                     </ul>
    36583650                  </li>
     
    36653657            </li>
    36663658            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    3667                   <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.4</b></a></li>
    3668                   <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.4</b></a></li>
    3669                   <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.4</b></a></li>
    3670                   <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.1</a>, <a href="#ISO-8859-1"><b>12.1</b></a></li>
     3659                  <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.3</b></a></li>
     3660                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
     3661                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
     3662                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.2</a>, <a href="#ISO-8859-1"><b>12.1</b></a></li>
    36713663               </ul>
    36723664            </li>
     
    36883680            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    36893681                  <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">6.1.1</a>, <a href="#Nie1997"><b>12.2</b></a></li>
    3690                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li>
     3682                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
    36913683               </ul>
    36923684            </li>
     
    36943686                  <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">4.1</a></li>
    36953687                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    3696                   <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.4</b></a></li>
     3688                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    36973689               </ul>
    36983690            </li>
    36993691            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37003692                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3701                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">2.4</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3693                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    37023694                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.1</a></li>
    37033695                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
     
    37073699                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
    37083700                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a></li>
    3709                         <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.4</a></li>
     3701                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    37103702                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">8.7</a></li>
    37113703                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">10.6</a></li>
     
    37213713                     </ul>
    37223714                  </li>
    3723                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
    3724                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.5</a></li>
     3715                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
     3716                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    37253717                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    37263718                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">8.1</a></li>
    3727                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li>
     3719                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li>
    37283720                     </ul>
    37293721                  </li>
    3730                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.4</b></a></li>
     3722                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    37313723               </ul>
    37323724            </li>
     
    37363728                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.7</b></a></li>
    37373729                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    3738                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li>
    3739                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>12.2</b></a></li>
     3730                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li>
     3731                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li>
    37403732                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    37413733                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
     
    37463738                     </ul>
    37473739                  </li>
    3748                   <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.1</a>, <a href="#RFC2047"><b>12.2</b></a></li>
     3740                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>12.2</b></a></li>
    37493741                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.4">6.2.3</a>, <a href="#RFC2068"><b>12.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>
    37503742                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
     
    37633755                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>12.2</b></a></li>
    37643756                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>12.2</b></a></li>
    3765                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>12.2</b></a></li>
     3757                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    37663758                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    37673759                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
     
    37833775                  <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">9.3</a>, <a href="#RFC4288"><b>12.2</b></a></li>
    37843776                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    3785                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.2</a>, <a href="#RFC4559"><b>12.2</b></a></li>
     3777                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    37863778                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
    37873779                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li>
    37883780                     </ul>
    37893781                  </li>
    3790                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">1.2.1</a>, <a href="#RFC5234"><b>12.1</b></a><ul>
     3782                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.2.5</a>, <a href="#RFC5234"><b>12.1</b></a><ul>
    37913783                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
    37923784                     </ul>
     
    38123804                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    38133805                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    3814                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
    3815                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
    3816                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.4</b></a></li>
     3806                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
     3807                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
     3808                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
    38173809               </ul>
    38183810            </li>
    38193811            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    38203812                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3821                   <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
     3813                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    38223814                  <li>URI scheme&nbsp;&nbsp;
    38233815                     <ul>
     
    38263818                     </ul>
    38273819                  </li>
    3828                   <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.1</a>, <a href="#USASCII"><b>12.1</b></a></li>
     3820                  <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.2</a>, <a href="#USASCII"><b>12.1</b></a></li>
    38293821                  <li>user agent&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>2.1</b></a></li>
    38303822               </ul>
    38313823            </li>
    38323824            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3833                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3825                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    38343826               </ul>
    38353827            </li>
Note: See TracChangeset for help on using the changeset viewer.