Changeset 1835 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 20/08/12 01:10:39 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1834 r1835 640 640 <li><a href="#rfc.section.5.5">5.5</a> <a href="#effective.request.uri">Effective Request URI</a></li> 641 641 <li><a href="#rfc.section.5.6">5.6</a> <a href="#message.forwarding">Message Forwarding</a></li> 642 <li><a href="#rfc.section.5.7">5.7</a> <a href="#message.transforming">Message Transforming</a></li> 643 <li><a href="#rfc.section.5.8">5.8</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 642 <li><a href="#rfc.section.5.7">5.7</a> <a href="#header.via">Via</a></li> 643 <li><a href="#rfc.section.5.8">5.8</a> <a href="#message.transforming">Message Transforming</a></li> 644 <li><a href="#rfc.section.5.9">5.9</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 644 645 </ul> 645 646 </li> 646 647 <li><a href="#rfc.section.6">6.</a> <a href="#connection.management">Connection Management</a><ul> 647 648 <li><a href="#rfc.section.6.1">6.1</a> <a href="#header.connection">Connection</a></li> 648 <li><a href="#rfc.section.6.2">6.2</a> <a href="#header.via">Via</a></li> 649 <li><a href="#rfc.section.6.3">6.3</a> <a href="#persistent.connections">Persistent Connections</a><ul> 650 <li><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#persistent.purpose">Purpose</a></li> 651 <li><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#persistent.overall">Overall Operation</a><ul> 652 <li><a href="#rfc.section.6.3.2.1">6.3.2.1</a> <a href="#persistent.negotiation">Negotiation</a></li> 653 <li><a href="#rfc.section.6.3.2.2">6.3.2.2</a> <a href="#pipelining">Pipelining</a></li> 649 <li><a href="#rfc.section.6.2">6.2</a> <a href="#persistent.connections">Persistent Connections</a><ul> 650 <li><a href="#rfc.section.6.2.1">6.2.1</a> <a href="#persistent.purpose">Purpose</a></li> 651 <li><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#persistent.overall">Overall Operation</a><ul> 652 <li><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a href="#persistent.negotiation">Negotiation</a></li> 653 <li><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a href="#pipelining">Pipelining</a></li> 654 654 </ul> 655 655 </li> 656 <li><a href="#rfc.section.6. 3.3">6.3.3</a> <a href="#persistent.practical">Practical Considerations</a></li>657 <li><a href="#rfc.section.6. 3.4">6.3.4</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li>656 <li><a href="#rfc.section.6.2.3">6.2.3</a> <a href="#persistent.practical">Practical Considerations</a></li> 657 <li><a href="#rfc.section.6.2.4">6.2.4</a> <a href="#persistent.retrying.requests">Retrying Requests</a></li> 658 658 </ul> 659 659 </li> 660 <li><a href="#rfc.section.6. 4">6.4</a> <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>661 <li><a href="#rfc.section.6. 4.1">6.4.1</a> <a href="#persistent.flow">Persistent Connections and Flow Control</a></li>662 <li><a href="#rfc.section.6. 4.2">6.4.2</a> <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>663 <li><a href="#rfc.section.6. 4.3">6.4.3</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>664 <li><a href="#rfc.section.6. 4.4">6.4.4</a> <a href="#closing.connections.on.error">Closing Connections on Error</a></li>660 <li><a href="#rfc.section.6.3">6.3</a> <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul> 661 <li><a href="#rfc.section.6.3.1">6.3.1</a> <a href="#persistent.flow">Persistent Connections and Flow Control</a></li> 662 <li><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li> 663 <li><a href="#rfc.section.6.3.3">6.3.3</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 664 <li><a href="#rfc.section.6.3.4">6.3.4</a> <a href="#closing.connections.on.error">Closing Connections on Error</a></li> 665 665 </ul> 666 666 </li> 667 <li><a href="#rfc.section.6. 5">6.5</a> <a href="#header.upgrade">Upgrade</a></li>667 <li><a href="#rfc.section.6.4">6.4</a> <a href="#header.upgrade">Upgrade</a></li> 668 668 </ul> 669 669 </li> … … 888 888 a proxy via some other connection port or protocol instead of using the defaults. 889 889 </p> 890 <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6. 3</a>.890 <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>. 891 891 </p> 892 892 <div id="rfc.iref.i.1"></div> … … 930 930 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 931 931 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 932 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 6.2</a>) header fields for both connections.932 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7</a>) header fields for both connections. 933 933 </p> 934 934 <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party … … 1517 1517 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data 1518 1518 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1519 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6. 3.2.2</a>.1519 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.2.2.2</a>. 1520 1520 </p> 1521 1521 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1850 1850 <p id="rfc.section.5.6.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. 1851 1851 </p> 1852 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="message.transforming" href="#message.transforming">Message Transforming</a></h2> 1853 <p id="rfc.section.5.7.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. 1854 </p> 1855 <p id="rfc.section.5.7.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1852 <div id="rfc.iref.v.1"></div> 1853 <div id="rfc.iref.h.12"></div> 1854 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.via" href="#header.via">Via</a></h2> 1855 <p id="rfc.section.5.7.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server 1856 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email 1857 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1858 of all senders along the request/response chain. 1859 </p> 1860 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 1861 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1862 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> 1863 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1864 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 1865 </pre><p id="rfc.section.5.7.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 1866 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 1867 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 1868 </p> 1869 <p id="rfc.section.5.7.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port 1870 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 1871 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 1872 </p> 1873 <p id="rfc.section.5.7.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 1874 </p> 1875 <p id="rfc.section.5.7.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 1876 </p> 1877 <p id="rfc.section.5.7.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 1878 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 1879 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1880 </p> 1881 <div id="rfc.figure.u.52"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1882 </pre><p id="rfc.section.5.7.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 1883 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1884 </p> 1885 <p id="rfc.section.5.7.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol 1886 values. For example, 1887 </p> 1888 <div id="rfc.figure.u.53"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1889 </pre><p id="rfc.section.5.7.p.12">could be collapsed to</p> 1890 <div id="rfc.figure.u.54"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1891 </pre><p id="rfc.section.5.7.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1892 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 1893 </p> 1894 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="message.transforming" href="#message.transforming">Message Transforming</a></h2> 1895 <p id="rfc.section.5.8.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. 1896 </p> 1897 <p id="rfc.section.5.8.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1856 1898 except as noted above to replace an empty path with "/" or "*". 1857 1899 </p> 1858 <p id="rfc.section.5. 7.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1859 </p> 1860 <p id="rfc.section.5. 7.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the1900 <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1901 </p> 1902 <p id="rfc.section.5.8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the 1861 1903 selected representation. 1862 1904 </p> 1863 <p id="rfc.section.5. 7.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:1905 <p id="rfc.section.5.8.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 1864 1906 </p> 1865 1907 <ul> … … 1877 1919 </li> 1878 1920 </ul> 1879 <p id="rfc.section.5. 7.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.1880 </p> 1881 <p id="rfc.section.5. 7.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:1921 <p id="rfc.section.5.8.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field. 1922 </p> 1923 <p id="rfc.section.5.8.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive: 1882 1924 </p> 1883 1925 <ul> … … 1889 1931 </li> 1890 1932 </ul> 1891 <p id="rfc.section.5. 7.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1892 </p> 1893 <div class="note" id="rfc.section.5. 7.p.9">1933 <p id="rfc.section.5.8.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1934 </p> 1935 <div class="note" id="rfc.section.5.8.p.9"> 1894 1936 <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced 1895 1937 in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 1896 1938 </p> 1897 1939 </div> 1898 <h2 id="rfc.section.5. 8"><a href="#rfc.section.5.8">5.8</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>1899 <p id="rfc.section.5. 8.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response1940 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1941 <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1900 1942 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1901 1943 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request. 1902 1944 </p> 1903 <p id="rfc.section.5. 8.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.1945 <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. 1904 1946 </p> 1905 1947 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connection.management" href="#connection.management">Connection Management</a></h1> 1906 1948 <div id="rfc.iref.c.13"></div> 1907 <div id="rfc.iref.h.1 2"></div>1949 <div id="rfc.iref.h.13"></div> 1908 1950 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1909 1951 <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such … … 1915 1957 </p> 1916 1958 <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p> 1917 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a>1959 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 1918 1960 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 1919 1961 </pre><p id="rfc.section.6.1.p.4">Connection options are compared case-insensitively.</p> … … 1940 1982 of the response. For example, 1941 1983 </p> 1942 <div id="rfc.figure.u.5 2"></div><pre class="text"> Connection: close1943 </pre><p id="rfc.section.6.1.p.11">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6. 3</a>) after the current request/response is complete.1984 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1985 </pre><p id="rfc.section.6.1.p.11">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) after the current request/response is complete. 1944 1986 </p> 1945 1987 <p id="rfc.section.6.1.p.12">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message. … … 1947 1989 <p id="rfc.section.6.1.p.13">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. 1948 1990 </p> 1949 <div id="rfc.iref.v.1"></div> 1950 <div id="rfc.iref.h.13"></div> 1951 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.via" href="#header.via">Via</a></h2> 1952 <p id="rfc.section.6.2.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server 1953 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email 1954 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1955 of all senders along the request/response chain. 1956 </p> 1957 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 1958 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1959 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> 1960 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1961 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 1962 </pre><p id="rfc.section.6.2.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 1963 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 1964 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 1965 </p> 1966 <p id="rfc.section.6.2.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port 1967 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 1968 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 1969 </p> 1970 <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 1971 </p> 1972 <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 1973 </p> 1974 <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 1975 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 1976 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1977 </p> 1978 <div id="rfc.figure.u.54"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1979 </pre><p id="rfc.section.6.2.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 1980 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1981 </p> 1982 <p id="rfc.section.6.2.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol 1983 values. For example, 1984 </p> 1985 <div id="rfc.figure.u.55"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1986 </pre><p id="rfc.section.6.2.p.12">could be collapsed to</p> 1987 <div id="rfc.figure.u.56"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1988 </pre><p id="rfc.section.6.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1989 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 1990 </p> 1991 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1992 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1993 <p id="rfc.section.6.3.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers 1991 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1992 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1993 <p id="rfc.section.6.2.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers 1994 1994 and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make 1995 1995 multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a 1996 1996 prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1997 1997 </p> 1998 <p id="rfc.section.6. 3.1.p.2">Persistent HTTP connections have a number of advantages: </p>1998 <p id="rfc.section.6.2.1.p.2">Persistent HTTP connections have a number of advantages: </p> 1999 1999 <ul> 2000 2000 <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, … … 2013 2013 </li> 2014 2014 </ul> 2015 <p id="rfc.section.6. 3.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.2016 </p> 2017 <h3 id="rfc.section.6. 3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>2018 <p id="rfc.section.6. 3.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior2015 <p id="rfc.section.6.2.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 2016 </p> 2017 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> 2018 <p id="rfc.section.6.2.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior 2019 2019 of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. 2020 2020 </p> 2021 <p id="rfc.section.6. 3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling2021 <p id="rfc.section.6.2.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 2022 2022 takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 2023 2023 </p> 2024 <h4 id="rfc.section.6. 3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>2025 <p id="rfc.section.6. 3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection2024 <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> 2025 <p id="rfc.section.6.2.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection 2026 2026 immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2027 2027 </p> 2028 <p id="rfc.section.6. 3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains2028 <p id="rfc.section.6.2.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains 2029 2029 a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that 2030 2030 request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2031 2031 </p> 2032 <p id="rfc.section.6. 3.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.2033 </p> 2034 <p id="rfc.section.6. 3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.2035 </p> 2036 <p id="rfc.section.6. 3.2.1.p.5">Each persistent connection applies to only one transport link.</p>2037 <p id="rfc.section.6. 3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).2038 </p> 2039 <p id="rfc.section.6. 3.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>.2040 </p> 2041 <h4 id="rfc.section.6. 3.2.2"><a href="#rfc.section.6.3.2.2">6.3.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>2042 <p id="rfc.section.6. 3.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.2043 </p> 2044 <p id="rfc.section.6. 3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.2045 </p> 2046 <p id="rfc.section.6. 3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2032 <p id="rfc.section.6.2.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection. 2033 </p> 2034 <p id="rfc.section.6.2.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2035 </p> 2036 <p id="rfc.section.6.2.2.1.p.5">Each persistent connection applies to only one transport link.</p> 2037 <p id="rfc.section.6.2.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2038 </p> 2039 <p id="rfc.section.6.2.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 2040 </p> 2041 <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> 2042 <p id="rfc.section.6.2.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. 2043 </p> 2044 <p id="rfc.section.6.2.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2045 </p> 2046 <p id="rfc.section.6.2.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2047 2047 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2048 2048 </p> 2049 <h3 id="rfc.section.6. 3.3"><a href="#rfc.section.6.3.3">6.3.3</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>2050 <p id="rfc.section.6. 3.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers2049 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> 2050 <p id="rfc.section.6.2.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers 2051 2051 might make this a higher value since it is likely that the client will be making more connections through the same server. 2052 2052 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 2053 2053 or the server. 2054 2054 </p> 2055 <p id="rfc.section.6. 3.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does2055 <p id="rfc.section.6.2.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does 2056 2056 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 2057 2057 </p> 2058 <p id="rfc.section.6. 3.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time2058 <p id="rfc.section.6.2.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time 2059 2059 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 2060 2060 while it was idle, but from the client's point of view, a request is in progress. 2061 2061 </p> 2062 <p id="rfc.section.6. 3.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).2063 </p> 2064 <p id="rfc.section.6. 3.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many2062 <p id="rfc.section.6.2.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies). 2063 </p> 2064 <p id="rfc.section.6.2.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many 2065 2065 applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages 2066 2066 clients to be conservative when opening multiple connections. 2067 2067 </p> 2068 <p id="rfc.section.6. 3.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant2068 <p id="rfc.section.6.2.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant 2069 2069 server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used 2070 2070 consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side 2071 2071 effects in congested networks. 2072 2072 </p> 2073 <p id="rfc.section.6. 3.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>2074 <h3 id="rfc.section.6. 3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>2075 <p id="rfc.section.6. 3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request2073 <p id="rfc.section.6.2.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> 2074 <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2075 <p id="rfc.section.6.2.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2076 2076 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2077 2077 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2078 2078 </p> 2079 <h2 id="rfc.section.6. 4"><a href="#rfc.section.6.4">6.4</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>2080 <h3 id="rfc.section.6. 4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>2081 <p id="rfc.section.6. 4.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating2079 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2> 2080 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3> 2081 <p id="rfc.section.6.3.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating 2082 2082 connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. 2083 2083 </p> 2084 <h3 id="rfc.section.6. 4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>2085 <p id="rfc.section.6. 4.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error2084 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 2085 <p id="rfc.section.6.3.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2086 2086 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. 2087 2087 </p> 2088 <h3 id="rfc.section.6. 4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>2089 <p id="rfc.section.6. 4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2088 <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2089 <p id="rfc.section.6.3.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2090 2090 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2091 2091 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without 2092 2092 looking at the body. 2093 2093 </p> 2094 <p id="rfc.section.6. 4.3.p.2">Requirements for HTTP/1.1 clients: </p>2094 <p id="rfc.section.6.3.3.p.2">Requirements for HTTP/1.1 clients: </p> 2095 2095 <ul> 2096 2096 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation. … … 2099 2099 </li> 2100 2100 </ul> 2101 <p id="rfc.section.6. 4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:2101 <p id="rfc.section.6.3.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 2102 2102 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has 2103 2103 never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. 2104 2104 </p> 2105 <p id="rfc.section.6. 4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>2105 <p id="rfc.section.6.3.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 2106 2106 <ul> 2107 2107 <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. … … 2123 2123 </li> 2124 2124 </ul> 2125 <p id="rfc.section.6. 4.3.p.5">Requirements for HTTP/1.1 proxies: </p>2125 <p id="rfc.section.6.3.3.p.5">Requirements for HTTP/1.1 proxies: </p> 2126 2126 <ul> 2127 2127 <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 … … 2135 2135 </li> 2136 2136 </ul> 2137 <h3 id="rfc.section.6. 4.4"><a href="#rfc.section.6.4.4">6.4.4</a> <a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>2138 <p id="rfc.section.6. 4.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes2137 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3> 2138 <p id="rfc.section.6.3.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes 2139 2139 the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send 2140 2140 a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted … … 2143 2143 <div id="rfc.iref.u.5"></div> 2144 2144 <div id="rfc.iref.h.14"></div> 2145 <h2 id="rfc.section.6. 5"><a href="#rfc.section.6.5">6.5</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2146 <p id="rfc.section.6. 5.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the2145 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2146 <p id="rfc.section.6.4.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2147 2147 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2148 2148 </p> … … 2152 2152 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2153 2153 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2154 </pre><p id="rfc.section.6. 5.p.3">For example,</p>2154 </pre><p id="rfc.section.6.4.p.3">For example,</p> 2155 2155 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2156 </pre><p id="rfc.section.6. 5.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible2156 </pre><p id="rfc.section.6.4.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2157 2157 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2158 2158 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2161 2161 the server, possibly according to the nature of the request method or target resource). 2162 2162 </p> 2163 <p id="rfc.section.6. 5.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.2163 <p id="rfc.section.6.4.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 2164 2164 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2165 2165 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2166 2166 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. 2167 2167 </p> 2168 <p id="rfc.section.6. 5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2169 </p> 2170 <p id="rfc.section.6. 5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it2168 <p id="rfc.section.6.4.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2169 </p> 2170 <p id="rfc.section.6.4.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2171 2171 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 2172 2172 </p> 2173 <p id="rfc.section.6. 5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching2173 <p id="rfc.section.6.4.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching 2174 2174 Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2175 2175 </p> 2176 <p id="rfc.section.6. 5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2176 <p id="rfc.section.6.4.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2177 2177 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.7</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2178 2178 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. … … 2243 2243 <td class="left">http</td> 2244 2244 <td class="left">standard</td> 2245 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6. 5</a>2245 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.4</a> 2246 2246 </td> 2247 2247 </tr> … … 2250 2250 <td class="left">http</td> 2251 2251 <td class="left">standard</td> 2252 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 6.2</a>2252 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7</a> 2253 2253 </td> 2254 2254 </tr> … … 2921 2921 </p> 2922 2922 <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. 2923 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section 6. 3.3</a>)2924 </p> 2925 <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section 6. 4</a>)2923 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section 6.2.3</a>) 2924 </p> 2925 <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain circumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section 6.3</a>) 2926 2926 </p> 2927 2927 <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p> 2928 2928 <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>) 2929 2929 </p> 2930 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6. 5</a>)2930 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.4</a>) 2931 2931 </p> 2932 2932 <p id="rfc.section.A.2.p.16">Take over the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>) … … 3517 3517 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3518 3518 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3519 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6. 3.2</a>, <a href="#rfc.xref.header.connection.7">6.5</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3519 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3520 3520 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3521 3521 </ul> … … 3550 3550 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3551 3551 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3552 <li><tt>Connection</tt> <a href="#rfc.iref.g. 85"><b>6.1</b></a></li>3553 <li><tt>connection-option</tt> <a href="#rfc.iref.g. 86"><b>6.1</b></a></li>3552 <li><tt>Connection</tt> <a href="#rfc.iref.g.91"><b>6.1</b></a></li> 3553 <li><tt>connection-option</tt> <a href="#rfc.iref.g.92"><b>6.1</b></a></li> 3554 3554 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.54"><b>3.3.2</b></a></li> 3555 3555 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> … … 3585 3585 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.8</b></a></li> 3586 3586 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.8</b></a></li> 3587 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.8 9"><b>6.2</b></a></li>3588 <li><tt>protocol-version</tt> <a href="#rfc.iref.g. 90"><b>6.2</b></a></li>3589 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.9 2"><b>6.2</b></a></li>3587 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>5.7</b></a></li> 3588 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>5.7</b></a></li> 3589 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>5.7</b></a></li> 3590 3590 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3591 3591 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> … … 3597 3597 <li><tt>rank</tt> <a href="#rfc.iref.g.78"><b>4.3</b></a></li> 3598 3598 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3599 <li><tt>received-by</tt> <a href="#rfc.iref.g. 91"><b>6.2</b></a></li>3600 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.8 8"><b>6.2</b></a></li>3599 <li><tt>received-by</tt> <a href="#rfc.iref.g.89"><b>5.7</b></a></li> 3600 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.86"><b>5.7</b></a></li> 3601 3601 <li><tt>request-line</tt> <a href="#rfc.iref.g.28"><b>3.1.1</b></a></li> 3602 3602 <li><tt>request-target</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> … … 3618 3618 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3619 3619 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3620 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6. 5</b></a></li>3620 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.4</b></a></li> 3621 3621 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.8</b></a></li> 3622 3622 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.8</b></a></li> 3623 3623 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3624 3624 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3625 <li><tt>Via</tt> <a href="#rfc.iref.g.8 7"><b>6.2</b></a></li>3625 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>5.7</b></a></li> 3626 3626 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3627 3627 </ul> … … 3634 3634 <li>Header Fields 3635 3635 <ul> 3636 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.1 2"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.3.2</a>, <a href="#rfc.xref.header.connection.7">6.5</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3636 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.2</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3637 3637 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3638 3638 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> … … 3640 3640 <li>Trailer <a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3641 3641 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3642 <li>Upgrade <a href="#rfc.iref.h.14"><b>6. 5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>3643 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.h.1 3"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3642 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3643 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3644 3644 </ul> 3645 3645 </li> … … 3675 3675 </li> 3676 3676 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3677 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">6. 3.1</a>, <a href="#Nie1997"><b>10.2</b></a></li>3677 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">6.2.1</a>, <a href="#Nie1997"><b>10.2</b></a></li> 3678 3678 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.4</b></a></li> 3679 3679 </ul> … … 3686 3686 </li> 3687 3687 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3688 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6. 3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>3689 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5. 7</a>, <a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">5.7</a>, <a href="#rfc.xref.Part2.20">5.7</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.4.3</a>, <a href="#rfc.xref.Part2.27">6.5</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3688 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.2.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3689 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a>, <a href="#rfc.xref.Part2.24">6.3.3</a>, <a href="#rfc.xref.Part2.25">6.3.3</a>, <a href="#rfc.xref.Part2.26">6.3.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3690 3690 <li><em>Section 2</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3691 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6. 3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a></li>3691 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6.2.2.2</a>, <a href="#rfc.xref.Part2.23">6.2.4</a></li> 3692 3692 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3693 3693 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3694 3694 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3695 3695 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li> 3696 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.21">5. 8</a>, <a href="#rfc.xref.Part2.26">6.4.3</a></li>3697 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.24">6. 4.3</a></li>3696 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3.3</a></li> 3697 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.24">6.3.3</a></li> 3698 3698 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.3">2.4</a></li> 3699 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.27">6. 5</a></li>3699 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.27">6.4</a></li> 3700 3700 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.30">8.6</a></li> 3701 3701 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li> 3702 3702 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li> 3703 3703 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">4.3</a></li> 3704 <li><em>Section 9.5</em> <a href="#rfc.xref.Part2.16">5. 7</a></li>3705 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.19">5. 7</a></li>3706 <li><em>Section 9.8</em> <a href="#rfc.xref.Part2.17">5. 7</a></li>3707 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.20">5. 7</a></li>3704 <li><em>Section 9.5</em> <a href="#rfc.xref.Part2.16">5.8</a></li> 3705 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.19">5.8</a></li> 3706 <li><em>Section 9.8</em> <a href="#rfc.xref.Part2.17">5.8</a></li> 3707 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.20">5.8</a></li> 3708 3708 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3709 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.25">6. 4.3</a></li>3710 <li><em>Section 9.17</em> <a href="#rfc.xref.Part2.18">5. 7</a></li>3709 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.25">6.3.3</a></li> 3710 <li><em>Section 9.17</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3711 3711 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3712 3712 </ul> 3713 3713 </li> 3714 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5. 7</a>, <a href="#rfc.xref.Part4.5">5.7</a>, <a href="#Part4"><b>10.1</b></a><ul>3715 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5. 7</a></li>3716 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5. 7</a></li>3714 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.8</a>, <a href="#rfc.xref.Part4.5">5.8</a>, <a href="#Part4"><b>10.1</b></a><ul> 3715 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5.8</a></li> 3716 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5.8</a></li> 3717 3717 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li> 3718 3718 </ul> 3719 3719 </li> 3720 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5. 7</a>, <a href="#Part5"><b>10.1</b></a><ul>3721 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5. 7</a></li>3720 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.8</a>, <a href="#Part5"><b>10.1</b></a><ul> 3721 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5.8</a></li> 3722 3722 </ul> 3723 3723 </li> 3724 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.5</a>, <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5. 7</a>, <a href="#rfc.xref.Part6.8">5.7</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>3724 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.5</a>, <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3725 3725 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2.5</a></li> 3726 3726 <li><em>Section 3</em> <a href="#rfc.xref.Part6.5">3.4</a></li> 3727 3727 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li> 3728 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5. 7</a></li>3729 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.8">5. 7</a></li>3728 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5.8</a></li> 3729 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.8">5.8</a></li> 3730 3730 </ul> 3731 3731 </li> … … 3751 3751 </li> 3752 3752 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3753 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">6. 3.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.4.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>3754 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6. 3.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>3753 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">6.2.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul> 3754 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li> 3755 3755 </ul> 3756 3756 </li> 3757 3757 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3758 3758 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3759 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.7</a>, <a href="#rfc.xref.RFC2616.3">5. 7</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul>3760 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5. 7</a></li>3759 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.7</a>, <a href="#rfc.xref.RFC2616.3">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">D.1</a><ul> 3760 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5.8</a></li> 3761 3761 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> 3762 3762 </ul> … … 3797 3797 </ul> 3798 3798 </li> 3799 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3"> 6.2</a>, <a href="#RFC5322"><b>10.2</b></a><ul>3800 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3"> 6.2</a></li>3799 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul> 3800 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">5.7</a></li> 3801 3801 </ul> 3802 3802 </li> … … 3807 3807 <li>sender <a href="#rfc.iref.s.3"><b>2.1</b></a></li> 3808 3808 <li>server <a href="#rfc.iref.s.1"><b>2.1</b></a></li> 3809 <li><em>Spe</em> <a href="#rfc.xref.Spe.1">6. 3.1</a>, <a href="#Spe"><b>10.2</b></a></li>3809 <li><em>Spe</em> <a href="#rfc.xref.Spe.1">6.2.1</a>, <a href="#Spe"><b>10.2</b></a></li> 3810 3810 <li>spider <a href="#rfc.iref.s.2"><b>2.1</b></a></li> 3811 3811 </ul> … … 3815 3815 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3816 3816 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.1</a>, <a href="#rfc.iref.t.6"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li> 3817 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6. 3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li>3817 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.2.1</a>, <a href="#Tou1998"><b>10.2</b></a></li> 3818 3818 <li>Trailer header field <a href="#rfc.iref.t.5"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3819 3819 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> … … 3824 3824 </li> 3825 3825 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3826 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6. 5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>3826 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3827 3827 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3828 3828 <li>URI scheme … … 3837 3837 </li> 3838 3838 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3839 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.v.1"><b> 6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3839 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3840 3840 </ul> 3841 3841 </li>
Note: See TracChangeset
for help on using the changeset viewer.