Ignore:
Timestamp:
20/08/12 06:04:26 (9 years ago)
Author:
fielding@…
Message:

start the plow through connection management

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1836 r1837  
    582582               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    583583               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li>
    584                <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
    585                <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    586                <li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
    587                <li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    588                <li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
    589                <li><a href="#rfc.section.2.8">2.8</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
    590                      <li><a href="#rfc.section.2.8.1">2.8.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
    591                      <li><a href="#rfc.section.2.8.2">2.8.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li>
    592                      <li><a href="#rfc.section.2.8.3">2.8.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
     584               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
     585               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     586               <li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     587               <li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
     588               <li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
     589                     <li><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
     590                     <li><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li>
     591                     <li><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
    593592                  </ul>
    594593               </li>
    … …  
    648647               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    649648               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    650                      <li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
    651                      <li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
    652                            <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
    653                            <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     649                     <li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
     650                           <li><a href="#rfc.section.6.2.1.1">6.2.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
     651                           <li><a href="#rfc.section.6.2.1.2">6.2.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    654652                        </ul>
    655653                     </li>
    656                      <li><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    657                      <li><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     654                     <li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
     655                     <li><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    658656                  </ul>
    659657               </li>
    … …  
    812810      <div id="rfc.iref.c.2"></div>
    813811      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Messaging</a></h2>
    814       <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) across a reliable transport or session-layer "<dfn>connection</dfn>". An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
     812      <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) across a reliable transport or session-layer "<dfn>connection</dfn>" (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>). An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
    815813      </p>
    816814      <div id="rfc.iref.u.1"></div>
    … …  
    842840         phrase (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>), possibly followed by header fields containing server information, resource metadata, and representation metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
    843841      </p>
    844       <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
     842      <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.2</a>.
     843      </p>
     844      <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>
    845845      <div id="rfc.figure.u.2"></div>
    846846      <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    … …  
    879879         run-time options, or simply not proceeding with the unsafe action.
    880880      </p>
    881       <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>
    882       <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
    883          transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request
    884          and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
    885       </p>
    886       <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 URI
    887          (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.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
    888          a proxy via some other connection port or protocol instead of using the defaults.
    889       </p>
    890       <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.2</a>.
    891       </p>
    892881      <div id="rfc.iref.i.1"></div>
    893       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    894       <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
     882      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
     883      <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
    895884         HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel,
    896885         switching behavior based on the nature of each request.
    … …  
    899888    <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b>
    900889               &lt;             &lt;             &lt;             &lt;
    901 </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
     890</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
    902891         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    903892         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along
    … …  
    906895         at the same time that it is handling A's request.
    907896      </p>
    908       <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.
     897      <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.
    909898         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.
    910899      </p>
    911       <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
     900      <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
    912901         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    913902         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    … …  
    915904         for the sake of security, annotation services, or shared caching.
    916905      </p>
    917       <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,
     906      <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,
    918907         beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original
    919908         sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared
    … …  
    923912         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 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    924913      </p>
    925       <p id="rfc.section.2.4.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
     914      <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
    926915         server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance
    927916         through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines.
    928917      </p>
    929       <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
     918      <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
    930919         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    931920         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    932921         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;5.7</a>) header fields for both connections.
    933922      </p>
    934       <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
     923      <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
    935924         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    936925         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    937926         when transport-layer security is used to establish confidential communication through a shared firewall proxy.
    938927      </p>
    939       <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> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     928      <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> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
    940929         intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the
    941930         knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems
    … …  
    945934         and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack.
    946935      </p>
    947       <p id="rfc.section.2.4.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
     936      <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
    948937         depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple
    949938         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
    … …  
    951940      </p>
    952941      <div id="rfc.iref.c.4"></div>
    953       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    954       <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.
     942      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
     943      <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.
    955944         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    956945         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.
    957946      </p>
    958       <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
     947      <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
    959948         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    960949         from O (via C) for a request which has not been cached by UA or A.
    … …  
    963952       <b>UA</b> =========== <b>A</b> =========== <b>B</b> - - - - - - <b>C</b> - - - - - - <b>O</b>
    964953                  &lt;             &lt;
    965 </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
     954</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
    966955         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    967956         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="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    968957      </p>
    969       <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
     958      <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
    970959         inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems
    971960         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so
    972961         on.
    973962      </p>
    974       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    975       <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     963      <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>
     964      <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
    976965         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    977966         or caches, depending on what behavior is being constrained by the requirement.
    978967      </p>
    979       <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     968      <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    980969         forwarding a received element downstream.
    981970      </p>
    982       <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     971      <p id="rfc.section.2.5.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    983972         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    984973      </p>
    985       <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, 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 that are applicable
     974      <p id="rfc.section.2.5.p.4">In addition to the prose requirements placed upon them, 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 that are applicable
    986975         to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
    987976         to the recipient's role.
    988977      </p>
    989       <p id="rfc.section.2.6.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
     978      <p id="rfc.section.2.5.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    990979         except when they have a direct impact on security, since different applications of the protocol require different error handling
    991980         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
    992981         to be dangerous.
    993982      </p>
    994       <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    995       <p id="rfc.section.2.7.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
     983      <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>
     984      <p id="rfc.section.2.6.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
    996985         The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's
    997986         corresponding specification of HTTP.
    998987      </p>
    999       <p id="rfc.section.2.7.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>
     988      <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>
    1000989      <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-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
    1001990  <a href="#http.version" class="smpl">HTTP-name</a>     = %x48.54.54.50 ; "HTTP", case-sensitive
    1002 </pre><p id="rfc.section.2.7.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
     991</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
    1003992         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    1004993         to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's
    … …  
    1006995         the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
    1007996      </p>
    1008       <p id="rfc.section.2.7.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
     997      <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
    1009998         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    1010999         so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt
    10111000         of a message, that the recipient supports HTTP/1.1.
    10121001      </p>
    1013       <p id="rfc.section.2.7.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
     1002      <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
    10141003         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    10151004         are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
    10161005      </p>
    1017       <p id="rfc.section.2.7.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
     1006      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    10181007         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    10191008         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
    10201009      </p>
    1021       <p id="rfc.section.2.7.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version
     1010      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version
    10221011         to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without
    10231012         rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version
    10241013         to determine what features are safe to use for later communication with that sender.
    10251014      </p>
    1026       <p id="rfc.section.2.7.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
     1015      <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
    10271016         than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
    10281017      </p>
    1029       <p id="rfc.section.2.7.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
     1018      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    10301019         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10311020      </p>
    1032       <p id="rfc.section.2.7.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
     1021      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
    10331022         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not
    10341023            Supported)</a> response if it cannot send a response using the major version used in the client's request.
    10351024      </p>
    1036       <p id="rfc.section.2.7.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
     1025      <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
    10371026         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    10381027         number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the
    10391028         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    10401029      </p>
    1041       <p id="rfc.section.2.7.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
     1030      <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    10421031         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    10431032         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    … …  
    10451034      </p>
    10461035      <div id="rfc.iref.r.5"></div>
    1047       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    1048       <p id="rfc.section.2.8.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects,
     1036      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
     1037      <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects,
    10491038         and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to
    10501039         interact with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
    10511040      </p>
    1052       <p id="rfc.section.2.8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
     1041      <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
    10531042         "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.
    10541043      </p>
    … …  
    10641053 
    10651054  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ]
    1066 </pre><p id="rfc.section.2.8.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
     1055</pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
    10671056         any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components,
    10681057         or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request
    10691058         URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
    10701059      </p>
    1071       <h3 id="rfc.section.2.8.1"><a href="#rfc.section.2.8.1">2.8.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
     1060      <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
    10721061      <div id="rfc.iref.h.1"></div>
    10731062      <div id="rfc.iref.u.3"></div>
    1074       <p id="rfc.section.2.8.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
     1063      <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    10751064         namespace governed by a potential HTTP origin server listening for TCP connections on a given port.
    10761065      </p>
    10771066      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></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> ]
    1078 </pre><p id="rfc.section.2.8.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
     1067</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
    10791068         identifier for a potential resource within that origin server's name space.
    10801069      </p>
    1081       <p id="rfc.section.2.8.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated
     1070      <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated
    10821071         TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient
    10831072         might use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
    10841073         port for WWW services).
    10851074      </p>
    1086       <p id="rfc.section.2.8.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
     1075      <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
    10871076         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
    10881077         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
    … …  
    10901079         authority to determine which names are valid and how they might be used.
    10911080      </p>
    1092       <p id="rfc.section.2.8.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     1081      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    10931082         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    10941083      </p>
    1095       <p id="rfc.section.2.8.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     1084      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    10961085         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    10971086         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
    … …  
    10991088         — it is only the authoritative interface used for mapping the namespace that is specific to TCP.
    11001089      </p>
    1101       <p id="rfc.section.2.8.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
     1090      <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    11021091         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    11031092         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages
    … …  
    11051094         is being used to obscure the authority for the sake of phishing attacks.
    11061095      </p>
    1107       <h3 id="rfc.section.2.8.2"><a href="#rfc.section.2.8.2">2.8.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3>
     1096      <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3>
    11081097      <div id="rfc.iref.h.2"></div>
    11091098      <div id="rfc.iref.u.4"></div>
    1110       <p id="rfc.section.2.8.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
     1099      <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    11111100         namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port.
    11121101      </p>
    1113       <p id="rfc.section.2.8.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
     1102      <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
    11141103         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 through the use of strong encryption prior to sending the first HTTP request.
    11151104      </p>
    11161105      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></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> ]
    1117 </pre><p id="rfc.section.2.8.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
     1106</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
    11181107         or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    11191108      </p>
    1120       <p id="rfc.section.2.8.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
     1109      <p id="rfc.section.2.7.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
    11211110         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered
    11221111         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the
    11231112         Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
    11241113      </p>
    1125       <p id="rfc.section.2.8.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    1126       </p>
    1127       <h3 id="rfc.section.2.8.3"><a href="#rfc.section.2.8.3">2.8.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
    1128       <p id="rfc.section.2.8.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to
     1114      <p id="rfc.section.2.7.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     1115      </p>
     1116      <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
     1117      <p id="rfc.section.2.7.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to
    11291118         the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a>, using the defaults described above for each scheme.
    11301119      </p>
    1131       <p id="rfc.section.2.8.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty
     1120      <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty
    11321121         path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme
    11331122         and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.
    11341123         Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see <a href="#RFC3986" id="rfc.xref.RFC3986.17"><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 normal form is to not encode them.
    11351124      </p>
    1136       <p id="rfc.section.2.8.3.p.3">For example, the following three URIs are equivalent:</p>
     1125      <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p>
    11371126      <div id="rfc.figure.u.10"></div><pre class="text">   http://example.com:80/~smith/home.html
    11381127   http://EXAMPLE.com/%7Esmith/home.html
    … …  
    15171506      <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
    15181507         on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple
    1519          requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.2.2.2</a>.
     1508         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.2.1.2</a>.
    15201509      </p>
    15211510      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    … …  
    16971686      </p>
    16981687      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1699          are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.8</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved
     1688         are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved
    17001689         for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    17011690      </p>
    … …  
    17151704         connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and
    17161705         defined by its associated specification, similar to how this specification defines origin server access for resolution of
    1717          the "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.8.2</a>) schemes.
     1706         the "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) schemes.
     1707      </p>
     1708      <p id="rfc.section.5.2.p.5">HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section&nbsp;6</a>.
    17181709      </p>
    17191710      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="request-target" href="#request-target">Request Target</a></h2>
    1720       <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on
     1711      <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on
    17211712         both the method being requested and whether the request is to a proxy.
    17221713      </p>
    … …  
    17811772         is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
    17821773      </p>
    1783       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.84"></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.8.1</a>
     1774      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.84"></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>
    17841775</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then the Host
    1785          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.8.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
     1776         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 URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    17861777      </p>
    17871778      <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    … …  
    18411832      </p>
    18421833      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2>
    1843       <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.4</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
     1834      <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
    18441835         to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
    18451836         characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can
    … …  
    19461937      </p>
    19471938      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
     1939      <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
     1940         transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request
     1941         and response structures onto the data units of an underlying transport protocol is outside the scope of this specification.
     1942      </p>
     1943      <p id="rfc.section.6.p.2">As described in <a href="#connecting.inbound" title="Connecting Inbound">Section&nbsp;5.2</a>, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the <a href="#target-resource" class="smpl">target URI</a>. 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
     1944         a proxy via some other connection, port, or protocol.
     1945      </p>
     1946      <p id="rfc.section.6.p.3">HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections,
     1947         establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection
     1948         failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection
     1949         per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request
     1950         queues to enable fair use and detect denial of service attacks.
     1951      </p>
    19481952      <div id="rfc.iref.c.13"></div>
    19491953      <div id="rfc.iref.h.13"></div>
    19501954      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    1951       <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
    1952          connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the
    1953          sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"),
    1954          as opposed to all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future
    1955          connection-specific extensions to be deployed in HTTP without fear that they will be blindly forwarded by previously deployed
    1956          intermediaries.
    1957       </p>
    1958       <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p>
     1955      <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to
     1956         avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message.
     1957      </p>
     1958      <p id="rfc.section.6.1.p.2">When a header field is used to supply control information for or about the current connection, the sender <em class="bcp14">SHOULD</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove
     1959         any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field
     1960         itself (or replace it with the intermediary's own connection options for the forwarded message).
     1961      </p>
     1962      <p id="rfc.section.6.1.p.3">Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the
     1963         immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling
     1964         the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they
     1965         will be blindly forwarded by older intermediaries.
     1966      </p>
     1967      <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p>
    19591968      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#header.connection" class="smpl">Connection</a>        = 1#<a href="#header.connection" class="smpl">connection-option</a>
    19601969  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    1961 </pre><p id="rfc.section.6.1.p.4">Connection options are compared case-insensitively.</p>
    1962       <p id="rfc.section.6.1.p.5">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove
    1963          any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field
    1964          itself or replace it with the sender's own connection options for the forwarded message.
    1965       </p>
    1966       <p id="rfc.section.6.1.p.6">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
     1970</pre><p id="rfc.section.6.1.p.6">Connection options are compared case-insensitively.</p>
     1971      <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    19671972         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    19681973      </p>
    1969       <p id="rfc.section.6.1.p.7">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
     1974      <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
    19701975         field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
    19711976         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-option rather than only the presence of the optional header field. In other
    … …  
    19741979         conformant.
    19751980      </p>
    1976       <p id="rfc.section.6.1.p.8">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
     1981      <p id="rfc.section.6.1.p.9">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
    19771982         that the new connection option does not share the same name as an unrelated header field that might already be deployed. Defining
    19781983         a new connection option essentially reserves that potential field-name for carrying additional information related to the
    19791984         connection option, since it would be unwise for senders to use that field-name for anything else.
    19801985      </p>
    1981       <p id="rfc.section.6.1.p.9">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
     1986      <p id="rfc.section.6.1.p.10">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    19821987         of the response. For example,
    19831988      </p>
    19841989      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    1985 </pre><p id="rfc.section.6.1.p.11">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.2</a>) after the current request/response is complete.
    1986       </p>
    1987       <p id="rfc.section.6.1.p.12">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
    1988       </p>
    1989       <p id="rfc.section.6.1.p.13">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code.
     1990</pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.2</a>).
     1991      </p>
     1992      <p id="rfc.section.6.1.p.13">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
     1993      </p>
     1994      <p id="rfc.section.6.1.p.14">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code.
    19901995      </p>
    19911996      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    1992       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
    1993       <p id="rfc.section.6.2.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
    1994          and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
    1995          multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
    1996          prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
    1997       </p>
    1998       <p id="rfc.section.6.2.1.p.2">Persistent HTTP connections have a number of advantages: </p>
    1999       <ul>
    2000          <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
    2001             tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
    2002          </li>
    2003          <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without
    2004             waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
    2005          </li>
    2006          <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to
    2007             determine the congestion state of the network.
    2008          </li>
    2009          <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li>
    2010          <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using
    2011             future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old
    2012             semantics after an error is reported.
    2013          </li>
    2014       </ul>
    2015       <p id="rfc.section.6.2.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
    2016       </p>
    2017       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
    2018       <p id="rfc.section.6.2.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
     1997      <p id="rfc.section.6.2.p.1">HTTP was originally designed to use a separate connection for each request/response pair. As the Web evolved and embedded
     1998         requests became common for inline images, the connection establishment overhead was a significant drain on performance and
     1999         a concern for Internet congestion. Message framing (via <a href="#header.content-length" class="smpl">Content-Length</a>) and optional long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order to improve performance for some requests.
     2000         However, these extensions were insufficient for dynamically generated responses and difficult to use with intermediaries.
     2001      </p>
     2002      <p id="rfc.section.6.2.p.2">HTTP/1.1 defaults to the use of "<a href="#persistent.connections" class="smpl">persistent connections</a>", which allow multiple requests and responses to be carried over a single connection. Persistent connections have a number
     2003         of advantages:
     2004      </p>
     2005      <ul>
     2006         <li>By opening and closing fewer connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels,
     2007            or caches), and memory used for protocol control blocks can be saved in hosts.
     2008         </li>
     2009         <li>Most requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without
     2010            waiting for each response, allowing a single connection to be used much more efficiently and with less overall latency.
     2011         </li>
     2012         <li>Network congestion is reduced by reducing the number of packets caused by connection establishment and tear-down, and by allowing
     2013            sufficient time for send/receive windows to adjust to the available network bandwidth.
     2014         </li>
     2015         <li>Latency on subsequent requests is reduced since there is no time spent in the connection opening handshake.</li>
     2016         <li>HTTP can evolve more gracefully, since most errors can be reported without the penalty of closing the connection. Clients
     2017            using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with
     2018            old semantics after an error is reported.
     2019         </li>
     2020      </ul>
     2021      <p id="rfc.section.6.2.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
     2022      </p>
     2023      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
     2024      <p id="rfc.section.6.2.1.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
    20192025         of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
    20202026      </p>
    2021       <p id="rfc.section.6.2.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
     2027      <p id="rfc.section.6.2.1.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    20222028         takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    20232029      </p>
    2024       <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    2025       <p id="rfc.section.6.2.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection
     2030      <h4 id="rfc.section.6.2.1.1"><a href="#rfc.section.6.2.1.1">6.2.1.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
     2031      <p id="rfc.section.6.2.1.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection
    20262032         immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    20272033      </p>
    2028       <p id="rfc.section.6.2.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
     2034      <p id="rfc.section.6.2.1.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    20292035         a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that
    20302036         request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    20312037      </p>
    2032       <p id="rfc.section.6.2.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.
    2033       </p>
    2034       <p id="rfc.section.6.2.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    2035       </p>
    2036       <p id="rfc.section.6.2.2.1.p.5">Each persistent connection applies to only one transport link.</p>
    2037       <p id="rfc.section.6.2.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
    2038       </p>
    2039       <p id="rfc.section.6.2.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
    2040       </p>
    2041       <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    2042       <p id="rfc.section.6.2.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
    2043       </p>
    2044       <p id="rfc.section.6.2.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    2045       </p>
    2046       <p id="rfc.section.6.2.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2038      <p id="rfc.section.6.2.1.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.
     2039      </p>
     2040      <p id="rfc.section.6.2.1.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
     2041      </p>
     2042      <p id="rfc.section.6.2.1.1.p.5">Each persistent connection applies to only one transport link.</p>
     2043      <p id="rfc.section.6.2.1.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     2044      </p>
     2045      <p id="rfc.section.6.2.1.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
     2046      </p>
     2047      <h4 id="rfc.section.6.2.1.2"><a href="#rfc.section.6.2.1.2">6.2.1.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
     2048      <p id="rfc.section.6.2.1.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
     2049      </p>
     2050      <p id="rfc.section.6.2.1.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
     2051      </p>
     2052      <p id="rfc.section.6.2.1.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20472053         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    20482054      </p>
    2049       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    2050       <p id="rfc.section.6.2.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
     2055      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     2056      <p id="rfc.section.6.2.2.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
    20512057         might make this a higher value since it is likely that the client will be making more connections through the same server.
    20522058         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    20532059         or the server.
    20542060      </p>
    2055       <p id="rfc.section.6.2.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
     2061      <p id="rfc.section.6.2.2.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
    20562062         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    20572063      </p>
    2058       <p id="rfc.section.6.2.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
     2064      <p id="rfc.section.6.2.2.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
    20592065         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    20602066         while it was idle, but from the client's point of view, a request is in progress.
    20612067      </p>
    2062       <p id="rfc.section.6.2.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
    2063       </p>
    2064       <p id="rfc.section.6.2.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
     2068      <p id="rfc.section.6.2.2.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     2069      </p>
     2070      <p id="rfc.section.6.2.2.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    20652071         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    20662072         clients to be conservative when opening multiple connections.
    20672073      </p>
    2068       <p id="rfc.section.6.2.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     2074      <p id="rfc.section.6.2.2.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    20692075         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    20702076         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    20712077         effects in congested networks.
    20722078      </p>
    2073       <p id="rfc.section.6.2.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
    2074       <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    2075       <p id="rfc.section.6.2.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
     2079      <p id="rfc.section.6.2.2.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
     2080      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
     2081      <p id="rfc.section.6.2.3.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    20762082         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    20772083         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    … …  
    21752181      </p>
    21762182      <p id="rfc.section.6.4.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    2177          by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
     2183         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    21782184         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    21792185      </p>
    … …  
    23002306                  <td class="left">http</td>
    23012307                  <td class="left">Hypertext Transfer Protocol</td>
    2302                   <td class="left"><a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a></td>
     2308                  <td class="left"><a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a></td>
    23032309               </tr>
    23042310               <tr>
    23052311                  <td class="left">https</td>
    23062312                  <td class="left">Hypertext Transfer Protocol Secure</td>
    2307                   <td class="left"><a href="#https.uri" title="https URI scheme">Section&nbsp;2.8.2</a></td>
     2313                  <td class="left"><a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a></td>
    23082314               </tr>
    23092315            </tbody>
    … …  
    25222528                  <td class="left">Hypertext Transfer Protocol</td>
    25232529                  <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td>
    2524                   <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a></td>
     2530                  <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a></td>
    25252531               </tr>
    25262532            </tbody>
    … …  
    26992705      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    27002706      </h2>
    2701       <table>                                                   
     2707      <table>                                           
    27022708         <tr>
    27032709            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
    … …  
    27072713            <td class="reference"><b id="Kri2001">[Kri2001]</b></td>
    27082714            <td class="top">Kristol, D., “<a href="http://arxiv.org/abs/cs.SE/0105018">HTTP Cookies: Standards, Privacy, and Politics</a>”, ACM Transactions on Internet Technology&nbsp;Vol. 1, #2, November&nbsp;2001, &lt;<a href="http://arxiv.org/abs/cs.SE/0105018">http://arxiv.org/abs/cs.SE/0105018</a>&gt;.
    2709             </td>
    2710          </tr>
    2711          <tr>
    2712             <td class="reference"><b id="Nie1997">[Nie1997]</b></td>
    2713             <td class="top">Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “<a href="http://doi.acm.org/10.1145/263105.263157">Network Performance Effects of HTTP/1.1, CSS1, and PNG</a>”, ACM&nbsp;Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication
    2714                SIGCOMM '97, September&nbsp;1997, &lt;<a href="http://doi.acm.org/10.1145/263105.263157">http://doi.acm.org/10.1145/263105.263157</a>&gt;.
    2715             </td>
    2716          </tr>
    2717          <tr>
    2718             <td class="reference"><b id="Pad1995">[Pad1995]</b></td>
    2719             <td class="top">Padmanabhan, V. and J. Mogul, “<a href="http://portal.acm.org/citation.cfm?id=219094">Improving HTTP Latency</a>”, Computer Networks and ISDN Systems&nbsp;v. 28, pp. 25-35, December&nbsp;1995, &lt;<a href="http://portal.acm.org/citation.cfm?id=219094">http://portal.acm.org/citation.cfm?id=219094</a>&gt;.
    27202715            </td>
    27212716         </tr>
    … …  
    28152810            </td>
    28162811         </tr>
    2817          <tr>
    2818             <td class="reference"><b id="Spe">[Spe]</b></td>
    2819             <td class="top">Spero, S., “<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">Analysis of HTTP Performance Problems</a>”, &lt;<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">http://sunsite.unc.edu/mdma-release/http-prob.html</a>&gt;.
    2820             </td>
    2821          </tr>
    2822          <tr>
    2823             <td class="reference"><b id="Tou1998">[Tou1998]</b></td>
    2824             <td class="top"><a href="mailto:touch@isi.edu" title="USC/Information Sciences Institute">Touch, J.</a>, <a href="mailto:johnh@isi.edu" title="USC/Information Sciences Institute">Heidemann, J.</a>, and <a href="mailto:katia@isi.edu" title="USC/Information Sciences Institute">K. Obraczka</a>, “<a href="http://www.isi.edu/touch/pubs/http-perf96/">Analysis of HTTP Performance</a>”, ISI Research Report&nbsp;ISI/RR-98-463, Aug&nbsp;1998, &lt;<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>&gt;.<br>(original report dated Aug. 1996)
    2825             </td>
    2826          </tr>
    28272812      </table>
    28282813      <div class="avoidbreak">
    … …  
    28952880      <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>
    28962881      <p id="rfc.section.A.2.p.1">Clarify that the string "HTTP" in the HTTP-version ABNF production is case sensitive. Restrict the version numbers to be single
    2897          digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a>)
     2882         digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>)
    28982883      </p>
    28992884      <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    … …  
    29212906      </p>
    29222907      <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    2923          Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.2.3</a>)
     2908         Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.2.2</a>)
    29242909      </p>
    29252910      <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section&nbsp;6.3</a>)
    … …  
    34913476            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    34923477                  <li>absolute-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
    3493                   <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.4</b></a></li>
     3478                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    34943479                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>7.3.2</b></a></li>
    34953480                  <li>asterisk-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
    … …  
    35023487            </li>
    35033488            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3504                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.5</b></a></li>
    3505                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li>
    3506                   <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
     3489                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
     3490                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
     3491                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    35073492                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
    35083493                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    … …  
    35173502                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    35183503                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3519                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3504                  <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">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    35203505                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    35213506               </ul>
    … …  
    35233508            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    35243509                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">4.2.2</a></li>
    3525                   <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
     3510                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    35263511               </ul>
    35273512            </li>
    … …  
    35313516            </li>
    35323517            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3533                   <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.4</b></a></li>
     3518                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.3</b></a></li>
    35343519                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35353520                     <ul>
    35363521                        <li><tt>absolute-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.3</b></a></li>
    3537                         <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.8</b></a></li>
     3522                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    35383523                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    35393524                        <li><tt>asterisk-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.3</b></a></li>
    35403525                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4</b></a></li>
    3541                         <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.8</b></a></li>
     3526                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
    35423527                        <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.3</b></a></li>
    35433528                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
    … …  
    35693554                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    35703555                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>3</b></a></li>
    3571                         <li><tt>HTTP-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.7</b></a></li>
    3572                         <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.8.1</b></a></li>
    3573                         <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.7</b></a></li>
    3574                         <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.8.2</b></a></li>
     3556                        <li><tt>HTTP-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.6</b></a></li>
     3557                        <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7.1</b></a></li>
     3558                        <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
     3559                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.7.2</b></a></li>
    35753560                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>4.1</b></a></li>
    35763561                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    … …  
    35823567                        <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.3</b></a></li>
    35833568                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
    3584                         <li><tt>partial-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.8</b></a></li>
    3585                         <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.8</b></a></li>
    3586                         <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.8</b></a></li>
     3569                        <li><tt>partial-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
     3570                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
     3571                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    35873572                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.7</b></a></li>
    35883573                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7</b></a></li>
    … …  
    35903575                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    35913576                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    3592                         <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.8</b></a></li>
     3577                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    35933578                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.2.4</b></a></li>
    35943579                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    … …  
    36193604                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    36203605                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.4</b></a></li>
    3621                         <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.8</b></a></li>
    3622                         <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.8</b></a></li>
     3606                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
     3607                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    36233608                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4</b></a></li>
    36243609                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    … …  
    36343619                  <li>Header Fields&nbsp;&nbsp;
    36353620                     <ul>
    3636                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3621                        <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">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.1</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    36373622                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    36383623                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    … …  
    36413626                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    36423627                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    3643                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3628                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    36443629                     </ul>
    36453630                  </li>
    … …  
    36473632                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    36483633                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    3649                   <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.8.1</b></a></li>
    3650                   <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.8.2</a></li>
     3634                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
     3635                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    36513636               </ul>
    36523637            </li>
    36533638            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    3654                   <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.4</b></a></li>
    3655                   <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.4</b></a></li>
    3656                   <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.4</b></a></li>
     3639                  <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.3</b></a></li>
     3640                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
     3641                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
    36573642                  <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>10.2</b></a></li>
    36583643               </ul>
    … …  
    36753660            </li>
    36763661            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    3677                   <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">6.2.1</a>, <a href="#Nie1997"><b>10.2</b></a></li>
    3678                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li>
     3662                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
    36793663               </ul>
    36803664            </li>
    … …  
    36823666                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    36833667                  <li>origin-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.3</a></li>
    3684                   <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.4</b></a></li>
     3668                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    36853669               </ul>
    36863670            </li>
    36873671            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3688                   <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.2.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    3689                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3672                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    36903673                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a></li>
    3691                         <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a></li>
     3674                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.1.2</a>, <a href="#rfc.xref.Part2.23">6.2.3</a></li>
    36923675                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    36933676                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    36943677                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3695                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>
     3678                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>
    36963679                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3.3</a></li>
    36973680                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.3</a></li>
    3698                         <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.4</a></li>
     3681                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    36993682                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.4</a></li>
    37003683                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">8.6</a></li>
    … …  
    37223705                     </ul>
    37233706                  </li>
    3724                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.5</a>, <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    3725                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.5</a></li>
     3707                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     3708                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.4</a></li>
    37263709                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.4</a></li>
    3727                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li>
     3710                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li>
    37283711                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">5.8</a></li>
    3729                         <li><em>Section 7.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.8">5.8</a></li>
     3712                        <li><em>Section 7.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.8</a></li>
    37303713                     </ul>
    37313714                  </li>
    37323715                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">1</a>, <a href="#Part7"><b>10.1</b></a></li>
    3733                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.4</b></a></li>
     3716                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    37343717               </ul>
    37353718            </li>
    … …  
    37383721                  <li>request&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li>
    37393722                  <li>request-target&nbsp;&nbsp;<a href="#rfc.iref.r.6">3.1.1</a></li>
    3740                   <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.8</b></a></li>
     3723                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.7</b></a></li>
    37413724                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    3742                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li>
    3743                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>10.2</b></a></li>
    3744                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.7</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li>
     3725                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li>
     3726                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li>
     3727                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li>
    37453728                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.5</a>, <a href="#RFC1950"><b>10.1</b></a></li>
    37463729                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li>
    … …  
    37513734                  </li>
    37523735                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3753                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">6.2.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
    3754                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
     3736                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
     3737                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
    37553738                     </ul>
    37563739                  </li>
    37573740                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
    37583741                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li>
    3759                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.7</a>, <a href="#rfc.xref.RFC2616.3">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul>
     3742                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul>
    37603743                        <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.8</a></li>
    37613744                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
    … …  
    37663749                     </ul>
    37673750                  </li>
    3768                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.8.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>
     3751                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>
    37693752                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>10.2</b></a></li>
    3770                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>10.2</b></a></li>
     3753                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>10.2</b></a></li>
    37713754                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li>
    3772                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#rfc.xref.RFC3986.2">2.8</a>, <a href="#rfc.xref.RFC3986.3">2.8</a>, <a href="#rfc.xref.RFC3986.4">2.8</a>, <a href="#rfc.xref.RFC3986.5">2.8</a>, <a href="#rfc.xref.RFC3986.6">2.8</a>, <a href="#rfc.xref.RFC3986.7">2.8</a>, <a href="#rfc.xref.RFC3986.8">2.8</a>, <a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a>, <a href="#rfc.xref.RFC3986.11">2.8</a>, <a href="#rfc.xref.RFC3986.12">2.8</a>, <a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a>, <a href="#rfc.xref.RFC3986.15">2.8.1</a>, <a href="#rfc.xref.RFC3986.16">2.8.3</a>, <a href="#rfc.xref.RFC3986.17">2.8.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>
    3773                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.8.3</a></li>
    3774                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.8</a></li>
    3775                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.8.1</a></li>
    3776                         <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a></li>
    3777                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.8</a></li>
    3778                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a></li>
    3779                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.8</a></li>
     3755                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">2.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">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>
     3756                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a></li>
     3757                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
     3758                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li>
     3759                        <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a></li>
     3760                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.7</a></li>
     3761                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a></li>
     3762                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.7</a></li>
    37803763                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.18">5.1</a></li>
    3781                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.8</a></li>
    3782                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.8</a></li>
    3783                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.8</a></li>
    3784                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.8.3</a></li>
     3764                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
     3765                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
     3766                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a></li>
     3767                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    37853768                     </ul>
    37863769                  </li>
    … …  
    37883771                  <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li>
    37893772                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li>
    3790                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.4</a>, <a href="#RFC4559"><b>10.2</b></a></li>
     3773                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li>
    37913774                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
    37923775                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li>
    … …  
    38013784                     </ul>
    38023785                  </li>
    3803                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.8.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
     3786                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
    38043787               </ul>
    38053788            </li>
    … …  
    38073790                  <li>sender&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>2.1</b></a></li>
    38083791                  <li>server&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>2.1</b></a></li>
    3809                   <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">6.2.1</a>, <a href="#Spe"><b>10.2</b></a></li>
    38103792                  <li>spider&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>2.1</b></a></li>
    38113793               </ul>
    … …  
    38153797                  <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.1</b></a></li>
    38163798                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.1</a>, <a href="#rfc.iref.t.6"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li>
    3817                   <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.2.1</a>, <a href="#Tou1998"><b>10.2</b></a></li>
    38183799                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.iref.t.5"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li>
    38193800                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    3820                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
    3821                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
    3822                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.4</b></a></li>
     3801                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
     3802                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
     3803                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
    38233804               </ul>
    38243805            </li>
    38253806            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    38263807                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    3827                   <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
     3808                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    38283809                  <li>URI scheme&nbsp;&nbsp;
    38293810                     <ul>
    3830                         <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.8.1</b></a></li>
    3831                         <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.8.2</a></li>
     3811                        <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.7.1</b></a></li>
     3812                        <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.7.2</a></li>
    38323813                     </ul>
    38333814                  </li>
    … …  
    38373818            </li>
    38383819            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3839                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3820                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    38403821               </ul>
    38413822            </li>
Note: See TracChangeset for help on using the changeset viewer.