W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

Re: Connection:Keep-Alive and Proxies

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
Message-ID: <Pine.BSF.4.44.0211260925360.19283-100000@measurement-factory.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:21 GMT