Ignore:
Timestamp:
Mar 13, 2011, 3:41:30 PM (9 years ago)
Author:
fielding@…
Message:

On second thought, gateways behave like user agents on the
inbound connection since they decide the inbound target resource.
The distinction is that HTTP-to-HTTP gateways must also implement
Connection and Via. Revises [1173] accordingly.

Improve definition of Connection header field to require that
the Conection field itself be removed (how did we forget that?)
and note the overlap between connection-token and field-name
namespaces. Addresses one half of #256 and #231.

File:
1 edited

Legend:

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

    r1174 r1175  
    969969      </p>
    970970      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span>  <span id="rfc.iref.a.1"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
    971          the received requests to the underlying server's protocol. Gateways are often used for load balancing, "accelerator" caching,
    972          or partitioning HTTP services across multiple machines. Gateways behave as an origin server on the outbound connection and
    973          as a proxy on the inbound connection. All HTTP requirements applicable to an origin server also apply to the outbound communication
    974          of a gateway. A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP
    975          that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party
    976          HTTP servers <em class="bcp14">SHOULD</em> comply with HTTP proxy requirements on the gateway's inbound connection.
    977       </p>
    978       <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
     971         the received requests to the underlying server's protocol. Gateways are often used to encapsulate legacy or untrusted information
     972         services, to improve server performance through "accelerator" caching, and to enable partitioning or load-balancing of HTTP
     973         services across multiple machines.
     974      </p>
     975      <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
     976         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
     977         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
     978         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>) header fields for both connections.
     979      </p>
     980      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    979981         a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist
    980982         when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,
    981983         such as when transport-layer security is used to establish private communication through a shared firewall proxy.
    982984      </p>
    983       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
     985      <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
    984986         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a
    985987         mess of things). Such a network intermediary, often referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "captive portal", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary
     
    10421044      <p id="rfc.section.2.5.p.8">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    10431045         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    1044          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
     1046         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10451047      </p>
    10461048      <p id="rfc.section.2.5.p.9">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
     
    13661368               <tr>
    13671369                  <td class="left">Connection</td>
    1368                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a></td>
     1370                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a></td>
    13691371               </tr>
    13701372               <tr>
     
    13861388               <tr>
    13871389                  <td class="left">Via</td>
    1388                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a></td>
     1390                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;9.9</a></td>
    13891391               </tr>
    13901392            </tbody>
     
    18471849      </p>
    18481850      <p id="rfc.section.7.1.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
    1849          takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     1851         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    18501852      </p>
    18511853      <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
     
    18731875      </p>
    18741876      <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
    1875       <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>.
     1877      <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;9.1</a>.
    18761878      </p>
    18771879      <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
     
    19021904      </ul>
    19031905      <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
    1904       <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;9.1</a>).
     1906      <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>).
    19051907      </p>
    19061908      <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
     
    20782080      </p>
    20792081      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    2080       <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
     2082      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP header fields related to message framing and transport protocols.</p>
    20812083      <div id="rfc.iref.c.12"></div>
    20822084      <div id="rfc.iref.h.6"></div>
    20832085      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    2084       <p id="rfc.section.9.1.p.1">The "Connection" header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
     2086      <p id="rfc.section.9.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
     2087         connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the
     2088         sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"),
     2089         as opposed to all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future
     2090         connection-specific extensions to be deployed in HTTP without fear that they will be blindly forwarded by previously deployed
     2091         intermediaries.
    20852092      </p>
    20862093      <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p>
     
    20882095  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
    20892096  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2090 </pre><p id="rfc.section.9.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header
    2091          field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a
    2092          connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional
    2093          header field might not be sent if there are no parameters associated with that connection option.
    2094       </p>
    2095       <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    2096       </p>
    2097       <p id="rfc.section.9.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
     2097</pre><p id="rfc.section.9.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
     2098         any header field(s) from the message with the same name as the connection-token, and then remove the Connection header field
     2099         itself or replace it with the sender's own connection options for the forwarded message.
     2100      </p>
     2101      <p id="rfc.section.9.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
     2102         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2103      </p>
     2104      <p id="rfc.section.9.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
     2105         field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
     2106         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
     2107         if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially
     2108         compliant.
     2109      </p>
     2110      <p id="rfc.section.9.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
     2111         that the new connection-token does not share the same name as an unrelated header field that might already be deployed. Defining
     2112         a new connection-token essentially reserves that potential field-name for carrying additional information related to the connection
     2113         option, since it would be unwise for senders to use that field-name for anything else.
     2114      </p>
     2115      <p id="rfc.section.9.1.p.8">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    20982116         of the response. For example,
    20992117      </p>
    21002118      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    2101 </pre><p id="rfc.section.9.1.p.8">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;7.1</a>) after the current request/response is complete.
    2102       </p>
    2103       <p id="rfc.section.9.1.p.9">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.
    2104       </p>
    2105       <p id="rfc.section.9.1.p.10">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 1xx (Informational) status code.
    2106       </p>
    2107       <p id="rfc.section.9.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header field <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the
    2108          connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a>.
     2119</pre><p id="rfc.section.9.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>) after the current request/response is complete.
     2120      </p>
     2121      <p id="rfc.section.9.1.p.11">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.
     2122      </p>
     2123      <p id="rfc.section.9.1.p.12">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 1xx (Informational) status code.
    21092124      </p>
    21102125      <div id="rfc.iref.c.13"></div>
     
    22162231  TE:
    22172232  TE: trailers, deflate;q=0.5
    2218 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
     2233</pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
    22192234      </p>
    22202235      <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     
    23022317         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.
    23032318      </p>
    2304       <p id="rfc.section.9.8.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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2319      <p id="rfc.section.9.8.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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    23052320      </p>
    23062321      <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     
    23392354      <div id="rfc.iref.h.15"></div>
    23402355      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2341       <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests,
    2342          and between the origin server and the client on responses. It is analogous to the "Received" field defined in <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.5"><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
     2356      <p id="rfc.section.9.9.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
     2357         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
     2358         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.5"><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
    23432359         of all senders along the request/response chain.
    23442360      </p>
     
    23552371         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    23562372      </p>
    2357       <p id="rfc.section.9.9.p.4">The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port
     2373      <p id="rfc.section.9.9.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
    23582374         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    23592375         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.
    23602376      </p>
    2361       <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy 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.
    2362       </p>
    2363       <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy, analogous to the User-Agent and Server header
     2377      <p id="rfc.section.9.9.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.
     2378      </p>
     2379      <p id="rfc.section.9.9.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 User-Agent and Server header
    23642380         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.
    23652381      </p>
     
    23692385      </p>
    23702386      <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2371 </pre><p id="rfc.section.9.9.p.9">Proxies used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    2372       </p>
    2373       <p id="rfc.section.9.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
     2387</pre><p id="rfc.section.9.9.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,
     2388         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
     2389      </p>
     2390      <p id="rfc.section.9.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
    23742391         For example,
    23752392      </p>
     
    23772394</pre><p id="rfc.section.9.9.p.12">could be collapsed to</p>
    23782395      <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2379 </pre><p id="rfc.section.9.9.p.14">Applications <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
    2380          by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     2396</pre><p id="rfc.section.9.9.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
     2397         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    23812398      </p>
    23822399      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     
    24002417                  <td class="left">http</td>
    24012418                  <td class="left">standard</td>
    2402                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>
     2419                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;9.1</a>
    24032420                  </td>
    24042421               </tr>
     
    24562473                  <td class="left">http</td>
    24572474                  <td class="left">standard</td>
    2458                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;9.9</a>
     2475                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;9.9</a>
    24592476                  </td>
    24602477               </tr>
     
    30473064         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    30483065         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
    3049          a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;9.1</a>.
     3066         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>.
    30503067      </p>
    30513068      <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
     
    30763093      <p id="rfc.section.B.3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
    30773094      </p>
    3078       <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>)
     3095      <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;9.1</a>)
    30793096      </p>
    30803097      <p id="rfc.section.B.3.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;9.8</a>)
     
    36173634                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    36183635                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3619                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
     3636                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>
    36203637                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    36213638               </ul>
     
    37603777                  <li>Header Fields&nbsp;&nbsp;
    37613778                     <ul>
    3762                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
     3779                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>
    37633780                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    37643781                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>
     
    37683785                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
    37693786                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.3</a></li>
    3770                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.2">10.1</a></li>
     3787                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>
    37713788                     </ul>
    37723789                  </li>
     
    39393956            </li>
    39403957            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3941                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">3.4</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.2">10.1</a></li>
     3958                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>
    39423959               </ul>
    39433960            </li>
Note: See TracChangeset for help on using the changeset viewer.