W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

keepalives and proxies: a request and a proposal

From: Lorenzo Vicisano <vicisano@iet.unipi.it>
Date: Fri, 17 Nov 1995 20:45:58 +0000 ()
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: vicisano@iet.unipi.it
Message-Id: <Pine.BSF.3.91.951117204324.5130D-100000@alex.iet.unipi.it>

I have a question and a proposal about keepalives.

From what I have seen, a client (C) connection to a server(S) sends

    Connection: Keep-Alive

to ask the server to keep the connection alive. When connecting to a
proxy(P), it sends instead

    Proxy-Connection: Keep-Alive

so that P can either understand it and transform it to

    Connection: Keep-Alive

when talking to S, or leave it untouched, in which case S can understand
that P cannot handle keepalives. This scheme does not cover the case of
a proxy talking to another proxy, e.g.

    C -------->  P1 ---->  P2  ------> S

Peeking at the list archives I have not seen a solution to the problem.
Has this already been discussed and/or solved ?

Otherwise, how about the following (which should also make the
distinction between "Connection:" and "Proxy-Connection:" redundant).

    A node (be it a client or a proxy) which likes the connection to
    stay up, will send

		Connection: Keep-Alive my-name

    my-name should be a unique identifier of the requesting node,
    e.g. the fully qualified hostname or the IP address.  The only
    requirement, it must be easily verifiable by other nodes (thus
    it cannot be the Ethernet address).

    A proxy receiving the ""Connection:" header as above can:

	* ignore it, or pass it unchanged to the next node;
	* replace "my-name" with its own name before sending it
	  to the next node (proxy or server);

    When the reply is sent up to the requesting node, each node in
    the chain which understands the "Connection:" header field will
    compare the name received as a parameter with the actual name
    of the previous node (e.g. derived by asking the peer's IP
    address of the connection). If they match, then the previous
    node wants the connection to stay up. If they don't, then the
    connection must be closed.

    This should work for arbitrarily long chains of nodes.

BTW, such an approach can be of general use whenever we want to
add backward-compatible options using proxies: compliant nodes just
replace the name field, non-compliant ones leave it untouched.

I would appreciate your comments on this solution.


 | Lorenzo Vicisano                     | http://www.iet.unipi.it/~vicisano |
 | Dip. di Ingegneria dell'Informazione | e-mail vicisano@iet.unipi.it      |
 | Universita' di Pisa                  | Phone  +39-50-568654              |
 | Via Diotisalvi, 2 56100 PISA, ITALY  | Fax    +39-50-568522              |
Received on Friday, 17 November 1995 11:55:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC