- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 26 Nov 2002 09:46:54 -0700 (MST)
- To: Diwakar Shetty <Diwakar.Shetty@oracle.com>
- cc: ietf-http-wg@w3.org
On Tue, 26 Nov 2002, Diwakar Shetty wrote: > Following is a para which i read in one book. I could not understand > it. Could somebody please elaborate > > --------------------------------------------------- > An HTTP/1.0 client could send a "Keep-Alive" header to a HTTP/1.1 > proxy that did not understand "Connection" but might mistakenly > forward it. If the downstream connection also maintained a > "Keep-Alive" connection, the proxy in the middle would never receive > the closing of the response > --------------------------------------------------- You may be slightly misquoting the book or the book may be slightly misquoting the protocol -- ``HTTP/1.1 proxy that did not understand Connection'' is an oxymoron. An exact quote from RFC 2616 (section 19.6.2) reads: The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. > My question, is why does it matter. The proxy will just relay > whatever comes from actual server to client. The problem is not with relaying bytes. That works just fine. The problem is with relaying the "end of message" information. Pure HTTP/1.0 applications rely on the [TCP] connection close to detect the end of a message. If the connection happens to be persistent, a pure HTTP/1.0 client will not detect the end of message for quite a while (until the connection is closed, which may happen minutes or even days after the original transaction). Such a delay in end of message detection is bad for at least three reasons: - various resources are wasted for nothing (it takes some CPU cycles, RAM, TPC ports, and possibly even network bandwidth to keep an idle connection open) - the end-user software may be indicating that "download" is still in progress; the user may be tempted to reload the page because it "got stuck", etc. - HTTP/1.0 clients used by an automated software package (e.g., web crawler or rsync) will block the caller preventing scheduled updates and such from happening [on time] HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance
Received on Tuesday, 26 November 2002 11:46:57 UTC