Ignore:
Timestamp:
20/08/12 01:10:39 (10 years ago)
Author:
fielding@…
Message:

move Via section up to routing (no changes)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1834 r1835  
    640640               <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    641641               <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a></li>
    642                <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.transforming">Message Transforming</a></li>
    643                <li><a href="#rfc.section.5.8">5.8</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     642               <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     643               <li><a href="#rfc.section.5.8">5.8</a>&nbsp;&nbsp;&nbsp;<a href="#message.transforming">Message Transforming</a></li>
     644               <li><a href="#rfc.section.5.9">5.9</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    644645            </ul>
    645646         </li>
    646647         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul>
    647648               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    648                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    649                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    650                      <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
    651                      <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
    652                            <li><a href="#rfc.section.6.3.2.1">6.3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
    653                            <li><a href="#rfc.section.6.3.2.2">6.3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     649               <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>
    654654                        </ul>
    655655                     </li>
    656                      <li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    657                      <li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></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>
    658658                  </ul>
    659659               </li>
    660                <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
    661                      <li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
    662                      <li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
    663                      <li><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    664                      <li><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#closing.connections.on.error">Closing Connections on Error</a></li>
     660               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
     661                     <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
     662                     <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
     663                     <li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
     664                     <li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#closing.connections.on.error">Closing Connections on Error</a></li>
    665665                  </ul>
    666666               </li>
    667                <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
     667               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    668668            </ul>
    669669         </li>
    … …  
    888888         a proxy via some other connection port or protocol instead of using the defaults.
    889889      </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.3</a>.
     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>.
    891891      </p>
    892892      <div id="rfc.iref.i.1"></div>
    … …  
    930930         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    931931         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    932          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;6.2</a>) header fields for both connections.
     932         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.
    933933      </p>
    934934      <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
    … …  
    15171517      <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
    15181518         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.3.2.2</a>.
     1519         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.2.2.2</a>.
    15201520      </p>
    15211521      <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>
    … …  
    18501850      <p id="rfc.section.5.6.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
    18511851      </p>
    1852       <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="message.transforming" href="#message.transforming">Message Transforming</a></h2>
    1853       <p id="rfc.section.5.7.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
    1854       </p>
    1855       <p id="rfc.section.5.7.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1852      <div id="rfc.iref.v.1"></div>
     1853      <div id="rfc.iref.h.12"></div>
     1854      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
     1855      <p id="rfc.section.5.7.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
     1856         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
     1857         systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
     1858         of all senders along the request/response chain.
     1859      </p>
     1860      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     1861                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     1862  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
     1863  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
     1864  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     1865</pre><p id="rfc.section.5.7.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     1866         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
     1867         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
     1868      </p>
     1869      <p id="rfc.section.5.7.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     1870         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
     1871         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
     1872      </p>
     1873      <p id="rfc.section.5.7.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     1874      </p>
     1875      <p id="rfc.section.5.7.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     1876      </p>
     1877      <p id="rfc.section.5.7.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     1878         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
     1879         server at www.example.com. The request received by www.example.com would then have the following Via header field:
     1880      </p>
     1881      <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     1882</pre><p id="rfc.section.5.7.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     1883         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
     1884      </p>
     1885      <p id="rfc.section.5.7.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
     1886         values. For example,
     1887      </p>
     1888      <div id="rfc.figure.u.53"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     1889</pre><p id="rfc.section.5.7.p.12">could be collapsed to</p>
     1890      <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     1891</pre><p id="rfc.section.5.7.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     1892         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     1893      </p>
     1894      <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="message.transforming" href="#message.transforming">Message Transforming</a></h2>
     1895      <p id="rfc.section.5.8.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     1896      </p>
     1897      <p id="rfc.section.5.8.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    18561898         except as noted above to replace an empty path with "/" or "*".
    18571899      </p>
    1858       <p id="rfc.section.5.7.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    1859       </p>
    1860       <p id="rfc.section.5.7.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
     1900      <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1901      </p>
     1902      <p id="rfc.section.5.8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
    18611903         selected representation.
    18621904      </p>
    1863       <p id="rfc.section.5.7.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
     1905      <p id="rfc.section.5.8.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    18641906      </p>
    18651907      <ul>
    … …  
    18771919         </li>
    18781920      </ul>
    1879       <p id="rfc.section.5.7.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.
    1880       </p>
    1881       <p id="rfc.section.5.7.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:
     1921      <p id="rfc.section.5.8.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.
     1922      </p>
     1923      <p id="rfc.section.5.8.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:
    18821924      </p>
    18831925      <ul>
    … …  
    18891931         </li>
    18901932      </ul>
    1891       <p id="rfc.section.5.7.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    1892       </p>
    1893       <div class="note" id="rfc.section.5.7.p.9">
     1933      <p id="rfc.section.5.8.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1934      </p>
     1935      <div class="note" id="rfc.section.5.8.p.9">
    18941936         <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced
    18951937            in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    18961938         </p>
    18971939      </div>
    1898       <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    1899       <p id="rfc.section.5.8.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
     1940      <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
     1941      <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19001942         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19011943         on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request.
    19021944      </p>
    1903       <p id="rfc.section.5.8.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
     1945      <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    19041946      </p>
    19051947      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
    19061948      <div id="rfc.iref.c.13"></div>
    1907       <div id="rfc.iref.h.12"></div>
     1949      <div id="rfc.iref.h.13"></div>
    19081950      <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>
    19091951      <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
    … …  
    19151957      </p>
    19161958      <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p>
    1917       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#header.connection" class="smpl">Connection</a>        = 1#<a href="#header.connection" class="smpl">connection-option</a>
     1959      <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>
    19181960  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    19191961</pre><p id="rfc.section.6.1.p.4">Connection options are compared case-insensitively.</p>
    … …  
    19401982         of the response. For example,
    19411983      </p>
    1942       <div id="rfc.figure.u.52"></div><pre class="text">  Connection: close
    1943 </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.3</a>) after the current request/response is complete.
     1984      <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.
    19441986      </p>
    19451987      <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.
    … …  
    19471989      <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.
    19481990      </p>
    1949       <div id="rfc.iref.v.1"></div>
    1950       <div id="rfc.iref.h.13"></div>
    1951       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    1952       <p id="rfc.section.6.2.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
    1953          on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    1954          systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    1955          of all senders along the request/response chain.
    1956       </p>
    1957       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    1958                           [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    1959   <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
    1960   <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    1961   <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1962 </pre><p id="rfc.section.6.2.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    1963          the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    1964          so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    1965       </p>
    1966       <p id="rfc.section.6.2.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    1967          number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    1968          be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    1969       </p>
    1970       <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    1971       </p>
    1972       <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    1973       </p>
    1974       <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    1975          HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    1976          server at www.example.com. The request received by www.example.com would then have the following Via header field:
    1977       </p>
    1978       <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    1979 </pre><p id="rfc.section.6.2.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    1980          the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    1981       </p>
    1982       <p id="rfc.section.6.2.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
    1983          values. For example,
    1984       </p>
    1985       <div id="rfc.figure.u.55"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    1986 </pre><p id="rfc.section.6.2.p.12">could be collapsed to</p>
    1987       <div id="rfc.figure.u.56"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    1988 </pre><p id="rfc.section.6.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    1989          by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    1990       </p>
    1991       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    1992       <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
    1993       <p id="rfc.section.6.3.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
     1991      <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
    19941994         and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
    19951995         multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
    19961996         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>.
    19971997      </p>
    1998       <p id="rfc.section.6.3.1.p.2">Persistent HTTP connections have a number of advantages: </p>
     1998      <p id="rfc.section.6.2.1.p.2">Persistent HTTP connections have a number of advantages: </p>
    19991999      <ul>
    20002000         <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
    … …  
    20132013         </li>
    20142014      </ul>
    2015       <p id="rfc.section.6.3.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
    2016       </p>
    2017       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
    2018       <p id="rfc.section.6.3.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
     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
    20192019         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.
    20202020      </p>
    2021       <p id="rfc.section.6.3.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
     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
    20222022         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.
    20232023      </p>
    2024       <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    2025       <p id="rfc.section.6.3.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
     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
    20262026         immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    20272027      </p>
    2028       <p id="rfc.section.6.3.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
     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
    20292029         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
    20302030         request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
    20312031      </p>
    2032       <p id="rfc.section.6.3.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.3.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.3.2.1.p.5">Each persistent connection applies to only one transport link.</p>
    2037       <p id="rfc.section.6.3.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.3.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.3.2.2"><a href="#rfc.section.6.3.2.2">6.3.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    2042       <p id="rfc.section.6.3.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.3.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.3.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
     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
    20472047         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.
    20482048      </p>
    2049       <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    2050       <p id="rfc.section.6.3.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
     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
    20512051         might make this a higher value since it is likely that the client will be making more connections through the same server.
    20522052         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    20532053         or the server.
    20542054      </p>
    2055       <p id="rfc.section.6.3.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
     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
    20562056         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    20572057      </p>
    2058       <p id="rfc.section.6.3.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
     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
    20592059         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    20602060         while it was idle, but from the client's point of view, a request is in progress.
    20612061      </p>
    2062       <p id="rfc.section.6.3.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.3.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
     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
    20652065         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    20662066         clients to be conservative when opening multiple connections.
    20672067      </p>
    2068       <p id="rfc.section.6.3.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     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
    20692069         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    20702070         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    20712071         effects in congested networks.
    20722072      </p>
    2073       <p id="rfc.section.6.3.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.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    2075       <p id="rfc.section.6.3.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
     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
    20762076         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
    20772077         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.
    20782078      </p>
    2079       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
    2080       <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
    2081       <p id="rfc.section.6.4.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
     2079      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
     2080      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
     2081      <p id="rfc.section.6.3.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
    20822082         connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
    20832083      </p>
    2084       <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    2085       <p id="rfc.section.6.4.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
     2084      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
     2085      <p id="rfc.section.6.3.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    20862086         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    20872087      </p>
    2088       <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2089       <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2088      <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
     2089      <p id="rfc.section.6.3.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    20902090         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    20912091         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    20922092         looking at the body.
    20932093      </p>
    2094       <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
     2094      <p id="rfc.section.6.3.3.p.2">Requirements for HTTP/1.1 clients: </p>
    20952095      <ul>
    20962096         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation.
    … …  
    20992099         </li>
    21002100      </ul>
    2101       <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
     2101      <p id="rfc.section.6.3.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    21022102         100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
    21032103         never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    21042104      </p>
    2105       <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
     2105      <p id="rfc.section.6.3.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21062106      <ul>
    21072107         <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    … …  
    21232123         </li>
    21242124      </ul>
    2125       <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p>
     2125      <p id="rfc.section.6.3.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    21262126      <ul>
    21272127         <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
    … …  
    21352135         </li>
    21362136      </ul>
    2137       <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>
    2138       <p id="rfc.section.6.4.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
     2137      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>
     2138      <p id="rfc.section.6.3.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    21392139         the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
    21402140         a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
    … …  
    21432143      <div id="rfc.iref.u.5"></div>
    21442144      <div id="rfc.iref.h.14"></div>
    2145       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2146       <p id="rfc.section.6.5.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2145      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2146      <p id="rfc.section.6.4.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    21472147         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    21482148      </p>
    … …  
    21522152  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    21532153  <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2154 </pre><p id="rfc.section.6.5.p.3">For example,</p>
     2154</pre><p id="rfc.section.6.4.p.3">For example,</p>
    21552155      <div id="rfc.figure.u.58"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2156 </pre><p id="rfc.section.6.5.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
     2156</pre><p id="rfc.section.6.4.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    21572157         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    21582158         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    21612161         the server, possibly according to the nature of the request method or target resource).
    21622162      </p>
    2163       <p id="rfc.section.6.5.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2163      <p id="rfc.section.6.4.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    21642164         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    21652165         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    21662166         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    21672167      </p>
    2168       <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2169       </p>
    2170       <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2168      <p id="rfc.section.6.4.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2169      </p>
     2170      <p id="rfc.section.6.4.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    21712171         is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
    21722172      </p>
    2173       <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
     2173      <p id="rfc.section.6.4.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
    21742174            Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    21752175      </p>
    2176       <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2176      <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
    21772177         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
    21782178         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    … …  
    22432243                  <td class="left">http</td>
    22442244                  <td class="left">standard</td>
    2245                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.5</a>
     2245                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.4</a>
    22462246                  </td>
    22472247               </tr>
    … …  
    22502250                  <td class="left">http</td>
    22512251                  <td class="left">standard</td>
    2252                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;6.2</a>
     2252                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7</a>
    22532253                  </td>
    22542254               </tr>
    … …  
    29212921      </p>
    29222922      <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.3.3</a>)
    2924       </p>
    2925       <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.4</a>)
     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>)
     2924      </p>
     2925      <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>)
    29262926      </p>
    29272927      <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p>
    29282928      <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
    29292929      </p>
    2930       <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.5</a>)
     2930      <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.4</a>)
    29312931      </p>
    29322932      <p id="rfc.section.A.2.p.16">Take over the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>)
    … …  
    35173517                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    35183518                  <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.3.2</a>, <a href="#rfc.xref.header.connection.7">6.5</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>
     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>
    35203520                  <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>
    35213521               </ul>
    … …  
    35503550                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a></li>
    35513551                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
    3552                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>6.1</b></a></li>
    3553                         <li><tt>connection-option</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>6.1</b></a></li>
     3552                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.1</b></a></li>
     3553                        <li><tt>connection-option</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>6.1</b></a></li>
    35543554                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>3.3.2</b></a></li>
    35553555                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    … …  
    35853585                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.8</b></a></li>
    35863586                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.8</b></a></li>
    3587                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.2</b></a></li>
    3588                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>6.2</b></a></li>
    3589                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>6.2</b></a></li>
     3587                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.7</b></a></li>
     3588                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7</b></a></li>
     3589                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>5.7</b></a></li>
    35903590                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    35913591                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    … …  
    35973597                        <li><tt>rank</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.3</b></a></li>
    35983598                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2</b></a></li>
    3599                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.2</b></a></li>
    3600                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>6.2</b></a></li>
     3599                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.7</b></a></li>
     3600                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>5.7</b></a></li>
    36013601                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3.1.1</b></a></li>
    36023602                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
    … …  
    36183618                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    36193619                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3620                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.5</b></a></li>
     3620                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.4</b></a></li>
    36213621                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.8</b></a></li>
    36223622                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.8</b></a></li>
    36233623                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4</b></a></li>
    36243624                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3625                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>6.2</b></a></li>
     3625                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.7</b></a></li>
    36263626                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
    36273627                     </ul>
    … …  
    36343634                  <li>Header Fields&nbsp;&nbsp;
    36353635                     <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.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.3.2</a>, <a href="#rfc.xref.header.connection.7">6.5</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>
     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>
    36373637                        <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>
    36383638                        <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>
    … …  
    36403640                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li>
    36413641                        <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>
    3642                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.5</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.13"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3642                        <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>
    36443644                     </ul>
    36453645                  </li>
    … …  
    36753675            </li>
    36763676            <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.3.1</a>, <a href="#Nie1997"><b>10.2</b></a></li>
     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>
    36783678                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li>
    36793679               </ul>
    … …  
    36863686            </li>
    36873687            <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.3.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.7</a>, <a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">5.7</a>, <a href="#rfc.xref.Part2.20">5.7</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.4.3</a>, <a href="#rfc.xref.Part2.27">6.5</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>
     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>
    36903690                        <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.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</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>
    36923692                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    36933693                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    36943694                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    36953695                        <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>
    3696                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.26">6.4.3</a></li>
    3697                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.4.3</a></li>
     3696                        <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>
     3697                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.3</a></li>
    36983698                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.4</a></li>
    3699                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.5</a></li>
     3699                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.4</a></li>
    37003700                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">8.6</a></li>
    37013701                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li>
    37023702                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li>
    37033703                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3</a></li>
    3704                         <li><em>Section 9.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.7</a></li>
    3705                         <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">5.7</a></li>
    3706                         <li><em>Section 9.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.7</a></li>
    3707                         <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.7</a></li>
     3704                        <li><em>Section 9.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.8</a></li>
     3705                        <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">5.8</a></li>
     3706                        <li><em>Section 9.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.8</a></li>
     3707                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
    37083708                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3709                         <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.4.3</a></li>
    3710                         <li><em>Section 9.17</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.7</a></li>
     3709                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3.3</a></li>
     3710                        <li><em>Section 9.17</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.8</a></li>
    37113711                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    37123712                     </ul>
    37133713                  </li>
    3714                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.7</a>, <a href="#rfc.xref.Part4.5">5.7</a>, <a href="#Part4"><b>10.1</b></a><ul>
    3715                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.7</a></li>
    3716                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.7</a></li>
     3714                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.8</a>, <a href="#rfc.xref.Part4.5">5.8</a>, <a href="#Part4"><b>10.1</b></a><ul>
     3715                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.8</a></li>
     3716                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.8</a></li>
    37173717                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
    37183718                     </ul>
    37193719                  </li>
    3720                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.7</a>, <a href="#Part5"><b>10.1</b></a><ul>
    3721                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">5.7</a></li>
     3720                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.8</a>, <a href="#Part5"><b>10.1</b></a><ul>
     3721                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">5.8</a></li>
    37223722                     </ul>
    37233723                  </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.7</a>, <a href="#rfc.xref.Part6.8">5.7</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     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>
    37253725                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.5</a></li>
    37263726                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.4</a></li>
    37273727                        <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>
    3728                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">5.7</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.7</a></li>
     3728                        <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>
    37303730                     </ul>
    37313731                  </li>
    … …  
    37513751                  </li>
    37523752                  <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.3.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.4.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.3.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</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>
    37553755                     </ul>
    37563756                  </li>
    37573757                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
    37583758                  <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.7</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>
    3760                         <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.7</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>
     3760                        <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.8</a></li>
    37613761                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
    37623762                     </ul>
    … …  
    37973797                     </ul>
    37983798                  </li>
    3799                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">6.2</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
    3800                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">6.2</a></li>
     3799                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
     3800                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>
    38013801                     </ul>
    38023802                  </li>
    … …  
    38073807                  <li>sender&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>2.1</b></a></li>
    38083808                  <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.3.1</a>, <a href="#Spe"><b>10.2</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>
    38103810                  <li>spider&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>2.1</b></a></li>
    38113811               </ul>
    … …  
    38153815                  <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.1</b></a></li>
    38163816                  <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.3.1</a>, <a href="#Tou1998"><b>10.2</b></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>
    38183818                  <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>
    38193819                  <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>
    … …  
    38243824            </li>
    38253825            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3826                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
     3826                  <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>
    38273827                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
    38283828                  <li>URI scheme&nbsp;&nbsp;
    … …  
    38373837            </li>
    38383838            <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>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     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>
    38403840               </ul>
    38413841            </li>
Note: See TracChangeset for help on using the changeset viewer.