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.

Location:
draft-ietf-httpbis/latest
Files:
2 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>

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

    r1173 r1175  
    709709   as a layer above some other server(s) and translates the received
    710710   requests to the underlying server's protocol.  Gateways are often
    711    used for load balancing, "accelerator" caching, or partitioning
    712    HTTP services across multiple machines.  Gateways behave as an origin
    713    server on the outbound connection and as a proxy on the inbound
    714    connection.  All HTTP requirements applicable to an origin server
    715    also apply to the outbound communication of a gateway.  A gateway
    716    communicates with inbound servers using any protocol it desires,
    717    including private extensions to HTTP that are outside the scope of
    718    this specification.  However, an HTTP-to-HTTP gateway that wishes
    719    to interoperate with third-party HTTP servers &SHOULD; comply with
    720    HTTP proxy requirements on the gateway's inbound connection.
     711   used to encapsulate legacy or untrusted information services, to
     712   improve server performance through "accelerator" caching, and to
     713   enable partitioning or load-balancing of HTTP services across
     714   multiple machines.
     715</t>
     716<t>
     717   A gateway behaves as an origin server on its outbound connection and
     718   as a user agent on its inbound connection.
     719   All HTTP requirements applicable to an origin server
     720   also apply to the outbound communication of a gateway.
     721   A gateway communicates with inbound servers using any protocol that
     722   it desires, including private extensions to HTTP that are outside
     723   the scope of this specification.  However, an HTTP-to-HTTP gateway
     724   that wishes to interoperate with third-party HTTP servers &MUST;
     725   comply with HTTP user agent requirements on the gateway's inbound
     726   connection and &MUST; implement the Connection
     727   (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
     728   header fields for both connections.
    721729</t>
    722730<t><iref primary="true" item="tunnel"/>
    … …  
    29382946<section title="Header Field Definitions" anchor="header.field.definitions">
    29392947<t>
    2940    This section defines the syntax and semantics of HTTP/1.1 header fields
     2948   This section defines the syntax and semantics of HTTP header fields
    29412949   related to message framing and transport protocols.
    29422950</t>
    … …  
    29502958<t>
    29512959   The "Connection" header field allows the sender to specify
    2952    options that are desired for that particular connection and &MUST-NOT;
    2953    be communicated by proxies over further connections.
     2960   options that are desired only for that particular connection.
     2961   Such connection options &MUST; be removed or replaced before the
     2962   message can be forwarded downstream by a proxy or gateway.
     2963   This mechanism also allows the sender to indicate which HTTP
     2964   header fields used in the message are only intended for the
     2965   immediate recipient ("hop-by-hop"), as opposed to all recipients
     2966   on the chain ("end-to-end"), enabling the message to be
     2967   self-descriptive and allowing future connection-specific extensions
     2968   to be deployed in HTTP without fear that they will be blindly
     2969   forwarded by previously deployed intermediaries.
    29542970</t>
    29552971<t>
    … …  
    29622978</artwork></figure>
    29632979<t>
    2964    HTTP/1.1 proxies &MUST; parse the Connection header field before a
    2965    message is forwarded and, for each connection-token in this field,
    2966    remove any header field(s) from the message with the same name as the
    2967    connection-token. Connection options are signaled by the presence of
    2968    a connection-token in the Connection header field, not by any
    2969    corresponding additional header field(s), since the additional header
    2970    field might not be sent if there are no parameters associated with that
    2971    connection option.
    2972 </t>
    2973 <t>
    2974    Message header fields listed in the Connection header field &MUST-NOT; include
    2975    end-to-end header fields, such as Cache-Control (&header-cache-control;).
     2980   A proxy or gateway &MUST; parse a received Connection
     2981   header field before a message is forwarded and, for each
     2982   connection-token in this field, remove any header field(s) from
     2983   the message with the same name as the connection-token, and then
     2984   remove the Connection header field itself or replace it with the
     2985   sender's own connection options for the forwarded message.
     2986</t>
     2987<t>
     2988   A sender &MUST-NOT; include field-names in the Connection header
     2989   field-value for fields that are defined as expressing constraints
     2990   for all recipients in the request or response chain, such as the
     2991   Cache-Control header field (&header-cache-control;).
     2992</t>
     2993<t>
     2994   The connection options do not have to correspond to a header field
     2995   present in the message, since a connection-specific header field
     2996   might not be needed if there are no parameters associated with that
     2997   connection option.  Recipients that trigger certain connection
     2998   behavior based on the presence of connection options &MUST; do so
     2999   based on the presence of the connection-token rather than only the
     3000   presence of the optional header field.  In other words, if the
     3001   connection option is received as a header field but not indicated
     3002   within the Connection field-value, then the recipient &MUST; ignore
     3003   the connection-specific header field because it has likely been
     3004   forwarded by an intermediary that is only partially compliant.
     3005</t>
     3006<t>
     3007   When defining new connection options, specifications ought to
     3008   carefully consider existing deployed header fields and ensure
     3009   that the new connection-token does not share the same name as
     3010   an unrelated header field that might already be deployed.
     3011   Defining a new connection-token essentially reserves that potential
     3012   field-name for carrying additional information related to the
     3013   connection option, since it would be unwise for senders to use
     3014   that field-name for anything else.
    29763015</t>
    29773016<t>
    … …  
    29963035   include the "close" connection option in every response message that
    29973036   does not have a 1xx (Informational) status code.
    2998 </t>
    2999 <t>
    3000    A system receiving an HTTP/1.0 (or lower-version) message that
    3001    includes a Connection header field &MUST;, for each connection-token in this
    3002    field, remove and ignore any header field(s) from the message with
    3003    the same name as the connection-token. This protects against mistaken
    3004    forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>.
    30053037</t>
    30063038</section>
    … …  
    34703502  <x:anchor-alias value="Via-v"/>
    34713503<t>
    3472    The "Via" header field &MUST; be sent by proxies to
     3504   The "Via" header field &MUST; be sent by a proxy or gateway to
    34733505   indicate the intermediate protocols and recipients between the user
    34743506   agent and the server on requests, and between the origin server and
    3475    the client on responses. It is analogous to the "Received" field defined in
    3476    <xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/> and is intended to be used for tracking message forwards,
     3507   the client on responses. It is analogous to the "Received" field
     3508   used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
     3509   and is intended to be used for tracking message forwards,
    34773510   avoiding request loops, and identifying the protocol capabilities of
    34783511   all senders along the request/response chain.
    … …  
    34973530</t>
    34983531<t>
    3499    The protocol-name is optional if and only if it would be "HTTP". The
     3532   The protocol-name is excluded if and only if it would be "HTTP". The
    35003533   received-by field is normally the host and optional port number of a
    35013534   recipient server or client that subsequently forwarded the message.
    … …  
    35053538</t>
    35063539<t>
    3507    Multiple Via field values represent each proxy that has
     3540   Multiple Via field values represent each proxy or gateway that has
    35083541   forwarded the message. Each recipient &MUST; append its information
    35093542   such that the end result is ordered according to the sequence of
    … …  
    35123545<t>
    35133546   Comments &MAY; be used in the Via header field to identify the software
    3514    of the recipient proxy, analogous to the User-Agent and
    3515    Server header fields. However, all comments in the Via field are
    3516    optional and &MAY; be removed by any recipient prior to forwarding the
    3517    message.
     3547   of each recipient, analogous to the User-Agent and Server header fields.
     3548   However, all comments in the Via field are optional and &MAY; be removed
     3549   by any recipient prior to forwarding the message.
    35183550</t>
    35193551<t>
    … …  
    35293561</artwork></figure>
    35303562<t>
    3531    Proxies used as a portal through a network firewall
    3532    &SHOULD-NOT;, by default, forward the names and ports of hosts within
    3533    the firewall region. This information &SHOULD; only be propagated if
    3534    explicitly enabled. If not enabled, the received-by host of any host
    3535    behind the firewall &SHOULD; be replaced by an appropriate pseudonym
    3536    for that host.
     3563   A proxy or gateway used as a portal through a network firewall
     3564   &SHOULD-NOT; forward the names and ports of hosts within the firewall
     3565   region unless it is explicitly enabled to do so. If not enabled, the
     3566   received-by host of any host behind the firewall &SHOULD; be replaced
     3567   by an appropriate pseudonym for that host.
    35373568</t>
    35383569<t>
    35393570   For organizations that have strong privacy requirements for hiding
    3540    internal structures, a proxy &MAY; combine an ordered subsequence of
    3541    Via header field entries with identical received-protocol values into
    3542    a single such entry. For example,
     3571   internal structures, a proxy or gateway &MAY; combine an ordered
     3572   subsequence of Via header field entries with identical received-protocol
     3573   values into a single such entry. For example,
    35433574</t>
    35443575<figure><artwork type="example">
    … …  
    35523583</artwork></figure>
    35533584<t>
    3554    Applications &SHOULD-NOT; combine multiple entries unless they are all
     3585   Senders &SHOULD-NOT; combine multiple entries unless they are all
    35553586   under the same organizational control and the hosts have already been
    3556    replaced by pseudonyms. Applications &MUST-NOT; combine entries which
     3587   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
    35573588   have different received-protocol values.
    35583589</t>
Note: See TracChangeset for help on using the changeset viewer.