Changeset 1175 for draft-ietf-httpbis/latest
- Timestamp:
- 13/03/11 22:41:30 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1174 r1175 969 969 </p> 970 970 <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 9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 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 979 981 a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist 980 982 when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, 981 983 such as when transport-layer security is used to establish private communication through a shared firewall proxy. 982 984 </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 nevertheless985 <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 984 986 act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 985 987 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 … … 1042 1044 <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 1043 1045 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 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 9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1045 1047 </p> 1046 1048 <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 … … 1366 1368 <tr> 1367 1369 <td class="left">Connection</td> 1368 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection. 2" title="Connection">Section 9.1</a></td>1370 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 9.1</a></td> 1369 1371 </tr> 1370 1372 <tr> … … 1386 1388 <tr> 1387 1389 <td class="left">Via</td> 1388 <td class="left"><a href="#header.via" id="rfc.xref.header.via. 1" title="Via">Section 9.9</a></td>1390 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 9.9</a></td> 1389 1391 </tr> 1390 1392 </tbody> … … 1847 1849 </p> 1848 1850 <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 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 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1850 1852 </p> 1851 1853 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> … … 1873 1875 </p> 1874 1876 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <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 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 9.1</a>. 1876 1878 </p> 1877 1879 <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 … … 1902 1904 </ul> 1903 1905 <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 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 9.1</a>). 1905 1907 </p> 1906 1908 <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> … … 2078 2080 </p> 2079 2081 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <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.1header 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> 2081 2083 <div id="rfc.iref.c.12"></div> 2082 2084 <div id="rfc.iref.h.6"></div> 2083 2085 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <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. 2085 2092 </p> 2086 2093 <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p> … … 2088 2095 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2089 2096 <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 2098 2116 of the response. For example, 2099 2117 </p> 2100 2118 <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 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 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 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. 2109 2124 </p> 2110 2125 <div id="rfc.iref.c.13"></div> … … 2216 2231 TE: 2217 2232 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 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 9.1</a>) whenever TE is present in an HTTP/1.1 message. 2219 2234 </p> 2220 2235 <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> … … 2302 2317 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. 2303 2318 </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 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 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2305 2320 </p> 2306 2321 <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 … … 2339 2354 <div id="rfc.iref.h.15"></div> 2340 2355 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <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 2343 2359 of all senders along the request/response chain. 2344 2360 </p> … … 2355 2371 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 2356 2372 </p> 2357 <p id="rfc.section.9.9.p.4">The protocol-name is optionalif and only if it would be "HTTP". The received-by field is normally the host and optional port2373 <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 2358 2374 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 2359 2375 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. 2360 2376 </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 header2377 <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 2364 2380 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. 2365 2381 </p> … … 2369 2385 </p> 2370 2386 <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. 2374 2391 For example, 2375 2392 </p> … … 2377 2394 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2378 2395 <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 replaced2380 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. 2381 2398 </p> 2382 2399 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 2400 2417 <td class="left">http</td> 2401 2418 <td class="left">standard</td> 2402 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection. 8" title="Connection">Section 9.1</a>2419 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 9.1</a> 2403 2420 </td> 2404 2421 </tr> … … 2456 2473 <td class="left">http</td> 2457 2474 <td class="left">standard</td> 2458 <td class="left"> <a href="#header.via" id="rfc.xref.header.via. 2" title="Via">Section 9.9</a>2475 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 9.9</a> 2459 2476 </td> 2460 2477 </tr> … … 3047 3064 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 3048 3065 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 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 9.1</a>. 3050 3067 </p> 3051 3068 <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 … … 3076 3093 <p id="rfc.section.B.3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>) 3077 3094 </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.1 0" title="Connection">Section 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 9.1</a>) 3079 3096 </p> 3080 3097 <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 9.8</a>) … … 3617 3634 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3618 3635 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3619 <li>Connection header field <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 <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> 3620 3637 <li>Content-Length header field <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> 3621 3638 </ul> … … 3760 3777 <li>Header Fields 3761 3778 <ul> 3762 <li>Connection <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 <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> 3763 3780 <li>Content-Length <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> 3764 3781 <li>Date <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> … … 3768 3785 <li>Transfer-Encoding <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> 3769 3786 <li>Upgrade <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 <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 <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> 3771 3788 </ul> 3772 3789 </li> … … 3939 3956 </li> 3940 3957 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3941 <li>Via header field <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 <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> 3942 3959 </ul> 3943 3960 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1173 r1175 709 709 as a layer above some other server(s) and translates the received 710 710 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. 721 729 </t> 722 730 <t><iref primary="true" item="tunnel"/> … … 2938 2946 <section title="Header Field Definitions" anchor="header.field.definitions"> 2939 2947 <t> 2940 This section defines the syntax and semantics of HTTP /1.1header fields2948 This section defines the syntax and semantics of HTTP header fields 2941 2949 related to message framing and transport protocols. 2942 2950 </t> … … 2950 2958 <t> 2951 2959 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. 2954 2970 </t> 2955 2971 <t> … … 2962 2978 </artwork></figure> 2963 2979 <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. 2976 3015 </t> 2977 3016 <t> … … 2996 3035 include the "close" connection option in every response message that 2997 3036 does not have a 1xx (Informational) status code. 2998 </t>2999 <t>3000 A system receiving an HTTP/1.0 (or lower-version) message that3001 includes a Connection header field &MUST;, for each connection-token in this3002 field, remove and ignore any header field(s) from the message with3003 the same name as the connection-token. This protects against mistaken3004 forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>.3005 3037 </t> 3006 3038 </section> … … 3470 3502 <x:anchor-alias value="Via-v"/> 3471 3503 <t> 3472 The "Via" header field &MUST; be sent by proxiesto3504 The "Via" header field &MUST; be sent by a proxy or gateway to 3473 3505 indicate the intermediate protocols and recipients between the user 3474 3506 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, 3477 3510 avoiding request loops, and identifying the protocol capabilities of 3478 3511 all senders along the request/response chain. … … 3497 3530 </t> 3498 3531 <t> 3499 The protocol-name is optionalif and only if it would be "HTTP". The3532 The protocol-name is excluded if and only if it would be "HTTP". The 3500 3533 received-by field is normally the host and optional port number of a 3501 3534 recipient server or client that subsequently forwarded the message. … … 3505 3538 </t> 3506 3539 <t> 3507 Multiple Via field values represent each proxy that has3540 Multiple Via field values represent each proxy or gateway that has 3508 3541 forwarded the message. Each recipient &MUST; append its information 3509 3542 such that the end result is ordered according to the sequence of … … 3512 3545 <t> 3513 3546 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. 3518 3550 </t> 3519 3551 <t> … … 3529 3561 </artwork></figure> 3530 3562 <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. 3537 3568 </t> 3538 3569 <t> 3539 3570 For organizations that have strong privacy requirements for hiding 3540 internal structures, a proxy &MAY; combine an ordered subsequence of3541 Via header field entries with identical received-protocol values into3542 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, 3543 3574 </t> 3544 3575 <figure><artwork type="example"> … … 3552 3583 </artwork></figure> 3553 3584 <t> 3554 Applications &SHOULD-NOT;combine multiple entries unless they are all3585 Senders &SHOULD-NOT; combine multiple entries unless they are all 3555 3586 under the same organizational control and the hosts have already been 3556 replaced by pseudonyms. Applications &MUST-NOT; combine entries which3587 replaced by pseudonyms. Senders &MUST-NOT; combine entries which 3557 3588 have different received-protocol values. 3558 3589 </t>
Note: See TracChangeset
for help on using the changeset viewer.