- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 20 Sep 2006 13:29:23 -0700
- To: Mark Nottingham <mnot@yahoo-inc.com>
- Cc: ietf-http-wg@w3.org
On Sep 20, 2006, at 10:08 AM, Mark Nottingham wrote: > HTTP/1.0 persistent connections are documented in RFC2068. One case > that's not explicitly covered is when a HTTP/1.1 client sends a > request to a HTTP/1.0 server without a Connection: keep-alive header. > > My reading of 2068, 2616 and 2145 is that the fact that the client > indicates HTTP/1.1 in the request advertises their support for > persistent connections, and a HTTP/1.0 server (whether origin or > proxy) may safely use a Content-Length delimited persistent response. What is an HTTP/1.0 server? > In my testing, two popular clients that advertise themselves as > HTTP/1.1 devices without sending a Connection token -- curl and > Apple's Safari -- handle persistent connections from HTTP/1.0 > servers very well. > > However, the widely deployed Squid proxy cache <http://www.squid- > cache.org/> does not behave in this manner; it requires a > Connection: keep-alive header (or Proxy-Connection, but that's > another discussion) in requests in order for them to persist. > > In discussion on their mailing list*, it seems they believe that > some HTTP/1.1 clients may not be able to handle a persistent > connection to a HTTP/1.0 server that they didn't explicitly "ask > for" with a Connection token. Maybe, though it is more likely that the client will adapt its behavior based on the contents of the response regardless of the request. A better question to ask is what happens to the connection if the client does not understand keep-alive? If the content-length is accurate, the HTTP/1.1 client should close the connection and everyone will be happy. However, the HTTP/1.1 client might be programmed or configured to assume that all HTTP/1.0 servers do a lousy job of setting content-length (which was true before keep-alive was deployed), so the client might just hold the connection open waiting for more content until the server times-out. I don't know of any clients that would do such a thing, just as I don't know of any HTTP/1.1 clients that don't implement HTTP/1.0 keep-alive. However, no clients should accept HTTP/1.0 keep-alive from a proxy because of the well-known problem with dumb-forwarding proxies. > What was the intent here? I can't imagine that it was the intent of > the WG to require HTTP/1.1 clients to send Connection tokens in > perpetuity for backwards compatibility. It was the intent of the WG that folks who claim to be using HTTP on the Internet should be doing so with HTTP/1.1, instead of making silly excuses not to. Anyone still claiming to use HTTP/1.0 will have to fend for themselves and test against every deployed system, since the only standard is for HTTP/1.1. ....Roy
Received on Wednesday, 20 September 2006 20:29:45 UTC