- 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