Re: Persistent and Keep-Alive in HTTP/1.1

> I still don't understand the point of having both Connection:
> Persistent and Connection: Keep-Alive (not to mention "Connection:
> keep-alive, persistent").  Having carefully read section E.2.5 and
> E.2.5.1 I understand that the chunked encoding may be used with
> persistent but not with keep-alive.  This seems to be the only
> difference.

The fifth paragragh of Section E.2.5 is poorly worded.  Keep-Alive
has no impact whatsoever on the use of chunked.  Change

      An HTTP/1.1 server may also establish persistent connections with
      HTTP/1.0 clients upon receipt of a Keep-Alive connection token.

      A persistent connection based on the Keep-Alive connection token MUST
      only use the _Content-Length_ technique for marking the ending
      boundaries of entity-bodies. It MAY use pipe-lining.

to

      An HTTP/1.1 server may also establish persistent connections with
      HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
      However, a persistent connection with an HTTP/1.0 client cannot
      make use of the chunked transfer-coding, and therefore MUST use
      a Content-Length for marking the ending boundary of each Entity-Body.

> Since persistent connections are one hop phenomena and every
> client/server/proxy knows whether its immediate neighbor is talking
> 1.0 or 1.1, why couldn't we always use use "keep-alive" to indicate a
> persistent connection.  It seems like both ends of a transaction will
> know if the chunked encoding is allowed since they know whether they
> are speaking 1.1 or later.  Chunked is required for 1.1 and not
> available for 1.0.  It seems redundant and obscure to code an "it's ok
> to use chunked" message in the Connection header since isn't needed
> anyway.
> 
> Is there something I am missing here?

The fear 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 dead 1.0 proxy waiting for the
close on the response.  The result is that 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 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.
As it turns out, there are two ways to accomplish that:

  1) Introduce a new keyword (persist) which is declared to be valid
     only when received from an HTTP/1.1 message.

  2) Declare persistence to be the default for HTTP/1.1 messages and
     introduce a new keyword (close) for declaring non-persistence.

[Jim, it might be useful to insert this into the keep-alive appendix as
rationale.]

I am inclined to go with the second option, since it gives us a better
migration path for future versions of the protocol and makes it easier
for us to eventually stop supporting some of the broken implementations
of keep-alive in existing practice.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 2 May 1996 03:01:48 UTC