Keepalives and proxies (hopefully solved)

Probably we have found a solution to the keepalive problem in
presence of cascaded proxies and tunnels. From his messages, it is
very likely that Roy already had this solution in mind (or has
possibly posted it); we cannot check because are currently disconnected
from both his mind and the mailing list archive.

** in the Request-Line header a node specifies the protocol it is
   speaking. The receiving node (unless it is a tunnel) is always able
   to understand it and must change the "HTTP-Version" according to
   what it can understand. [we haven't checked if pre-1.0 proxies
   actually behave this way]

   Thus, any node knows the protocol spoken by the previous one in the
   request chain.

** a "Connection: keepalive" (possibly with other flags, but
   *without* the node ID) can only be generated by nodes speaking
   1.1 and greater versions of the protocol.
   Nodes speaking 1.0 or earlier versions of http *should not*
   generate such an header, as it is not in the spec.
   Unfortunately some do...
   following node must not honor the request).

** A 1.0 node receiving the "Connection: ..." header should just ignore
   it and pass it down the link.

** A 1.1 node receiving the "Connection: ..." header should parse it,
   determine if it comes from a 1.1-capable node, and possibly
   honor it (it should not be mandatory, though).

   If the header comes from a 1.0 node, the request *must not* be
   honored.

** A 1.1 node can autonomously decide to pass, insert or delete a
   "Connection: ..." header according to its own policies.

** A tunnel receiving the "Connection:... " header, just passes it down
   the link unchanged.

Note the difference between this approach and the "Connection:
keepalive my-id" one. The former only works because of a difference
in the protocol version, the latter can be used to negotiate options
even without changing the protocol version, but is not applicable in
presence of tunnels.

Note also that the two approaches can coexist, i.e. 1.0 nodes could
send a "Connection: keepalive my-id", and 1.1 nodes could try to
honor the request if the peer matches the id specified in the
request. In the spirit of the "robustness principle" (RFC793,
sec.2.10):

    be conservative in what you do, be liberal in what you accept
    from others

it wouldn't be a bad idea to include an optional id field in the
"Connection: header".

	Lorenzo and Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Received on Wednesday, 22 November 1995 10:57:22 UTC