Changeset 1492 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 14/12/11 03:21:58 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1491 r1492 4899 4899 <section title="Keep-Alive Connections" anchor="compatibility.with.http.1.0.persistent.connections"> 4900 4900 <t> 4901 For most implementations of HTTP/1.0, each connection is established 4902 by the client prior to the request and closed by the server after 4903 sending the response. However, some implementations implement the 4904 Keep-Alive version of persistent connections described in 4905 <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4906 </t> 4907 <t> 4908 Some clients and servers might wish to be compatible with some 4909 previous implementations of persistent connections in HTTP/1.0 4910 clients and servers. Persistent connections in HTTP/1.0 are 4911 explicitly negotiated as they are not the default behavior. HTTP/1.0 4912 experimental implementations of persistent connections are faulty, 4913 and the new facilities in HTTP/1.1 are designed to rectify these 4914 problems. The problem was that some existing HTTP/1.0 clients might 4915 send Keep-Alive to a proxy server that doesn't understand 4916 Connection, which would then erroneously forward it to the next 4917 inbound server, which would establish the Keep-Alive connection and 4918 result in a hung HTTP/1.0 proxy waiting for the close on the 4919 response. The result is that HTTP/1.0 clients must be prevented from 4920 using Keep-Alive when talking to proxies. 4921 </t> 4922 <t> 4923 However, talking to proxies is the most important use of persistent 4924 connections, so that prohibition is clearly unacceptable. Therefore, 4925 we need some other mechanism for indicating a persistent connection 4926 is desired, which is safe to use even when talking to an old proxy 4927 that ignores Connection. Persistent connections are the default for 4928 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 4929 declaring non-persistence. See <xref target="header.connection"/>. 4901 In HTTP/1.0, each connection is established by the client prior to the 4902 request and closed by the server after sending the response. However, some 4903 implementations implement the explicitly negotiated ("Keep-Alive") version 4904 of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" 4905 target="RFC2068"/>. 4906 </t> 4907 <t> 4908 Some clients and servers might wish to be compatible with these previous 4909 approaches to persistent connections, by explicitly negotiating for them 4910 with a "Connection: keep-alive" request header field. However, some 4911 experimental implementations of HTTP/1.0 persistent connections are faulty; 4912 for example, if a HTTP/1.0 proxy server doesn't understand Connection, it 4913 will erroneously forward that header to the next inbound server, which 4914 would result in a hung connection. 4915 </t> 4916 <t> 4917 One attempted solution was the introduction of a Proxy-Connection header, 4918 targeted specifically at proxies. In practice, this was also unworkable, 4919 because proxies are often deployed in multiple layers, bringing about the 4920 same problem discussed above. 4921 </t> 4922 <t> 4923 As a result, clients are encouraged not to send the Proxy-Connection header 4924 in any requests. 4925 </t> 4926 <t> 4927 Clients are also encouraged to consider the use of Connection: keep-alive 4928 in requests carefully; while they can enable persistent connections with 4929 HTTP/1.0 servers, clients using them need will need to monitor the 4930 connection for "hung" requests (which indicate that the client ought stop 4931 sending the header), and this mechanism ought not be used by clients at all 4932 when a proxy is being used. 4930 4933 </t> 4931 4934 </section> … … 5892 5895 "Intermediary rewriting of queries" 5893 5896 </t> 5897 <t> 5898 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/158"/>: 5899 "Proxy-Connection and Keep-Alive" 5900 </t> 5894 5901 </list> 5895 5902 </t>
Note: See TracChangeset
for help on using the changeset viewer.