Re: Connection:Keep-Alive and Proxies

On Wed, 27 Nov 2002, Diwakar Shetty wrote:

> > > ---------------------------------------------------
> > > 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.
>
> The book is referring to HTTP/1.1 proxy and not HTTP/1.0 proxy

I think the book is misquoting the RFC. Again, there is no such thing
as HTTP/1.1 proxy that does not understand Connection header because
Connection: support is a MUST. But the terminology is not important
here. I suspect you are more interested in a real-world problem the
RFC talks about rather than in trying to interpret the book :-).

> It concludes at the end...."HTTP/1.1 proxies are not permitted to
> establish a persistent connection with HTTP/1.0 clients

I hope that's not the end! RFC 2616 comes to the same
conclusion, of course, but then continues:

   The result is that HTTP/1.0 clients must be prevented from
   using Keep-Alive when talking to proxies.

   However, talking to proxies is the most important use of persistent
   connections, so that prohibition is clearly unacceptable. Therefore,
   we need some other mechanism for indicating a persistent connection
   is desired, which is safe to use even when talking to an old proxy
   that ignores Connection. Persistent connections are the default for
   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
   declaring non-persistence. See section 14.10.

   The original HTTP/1.0 form of persistent connections (the Connection:
   Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]

As you can see, the problem is solved as long as the client is
HTTP/1.1.

> > 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
> >
>
> But it was the HTTP/1.0 client which sent the "Keep-alive" in the
> first place Hence it is not pure.

Proxy is a client in the above context. You need to draw a picture:

	client C (end-client or proxy)
	(issues Connection: keep-alive)
	       |
	       |
	proxy P
	(forwards Connection: keep-alive,
	 does not understand persistency and works as a tunnel)
	       |
	       |
	server S (origin or proxy)
	(establishes persistent connection: technically with proxy A,
	 but, essentially, with client C, which is wrong)

Now, server S will not close the connection after the response is
sent.  End-client C may be fine because it knows how to detect the end
of the response. Proxy P will get stuck though because it will wait
for connection close from server S.

> It intentionally wants to keep the Connection alive Hence, the
> client can detect the end of message using "Content-length" sent by
> the origin server, as mentioned by Scott

True, but the problem is not with client C. The problem is with proxy
P. See above. Now imagine that proxy P does not forward small
responses until they are "completely received"; in this case, client C
gets stuck as well!

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 Wednesday, 27 November 2002 00:47:24 UTC