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

Re: keepalives and proxies: a request and a proposal

From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Date: Sat, 18 Nov 1995 11:11:29 +0100 (MET)
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: Jeffrey Mogul <mogul@pa.dec.com>, Lorenzo Vicisano <vicisano@iet.unipi.it>, http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.BSF.3.91.951118105010.8434A-100000@labinfo.iet.unipi.it>
On Fri, 17 Nov 1995, Roy T. Fielding wrote:

> I was referring to the Proxy-Connection thingy in Alex's draft, which
> will not be in HTTP/1.1.  The IP thingy has other problems.
> 
> > Roy sez:
> >     The only way to differentiate communication capabilities is through
> >     the protocol name + version number, since that is the only feature
> >     that cannot be passed on by a proxy.
> > The implication is that the 1.1 protocol spec will say something
> > like "a client or proxy must not send or forward a Keepalive:
> > header to a proxy [or server?] with a version number below 1.1".
> > Is that what you are planning, Roy?
> 
> No, it says a recipient cannot trust a Connection header received from
> an HTTP/1.0 message.  This can't be replaced by including the IP number
> in the header field because the IP is changed when sent through a tunnel.
> The only general way to solve this problem is to change to HTTP/1.1.

I don't know what is the exact definition of a tunnel, but with the
most intuitive one (an object which passes data bidirectionally,
and closes the connection when either side closes), a tunnel is 
intrinsically "not compliant" with any protocol. Thus, any technique to 
distinguish between a tunnel and a proxy running an old version of
the protocol can only try to exploit some feature of the old protocol.

Also, with reference to my previous posting:
 
> Neither do I. The only setting where this cannot work is where the two
> proxies are connected through a tunnel, e.g.
> 
>         C --- P1 ---- T ---- P2 --- S
>
> and T is passing bidirectional data without interpreting them. How
> common is this setting, I don't know. Especially, I don't know if
> it can be useful.

It is not that this does not work, it merely cause P1 and P2 to close the 
connection as if the other side were not compliant (provided that there 
is not another way to tell that there is a tunnel in between).
It's just a matter of efficiency, but it does work.

> > One problem that the "Keepalive: myaddress" approach seems to
> > solve better than the version-number based approach is that it
> > allows a 1.1 proxy to not implement persistent connections.
> > That is, under Roy's approach, persistent connection support
> > would have to be 100% mandatory for all 1.1 (and later) proxies.
> 
> Nope -- removal/replacement of the Connection header, and any header fields
> named within the Connection header, will be mandatory.
> 
> > Under the alternate approach, any proxy not wanting to support
> > persistent connections (either for implementation reasons or
> > for policy reasons) could simply drop the "Keepalive: myaddress"
> > header.
> 
> Persistent connections are identified by the keep-alive keyword in
> the Connection header -- the Keep-Alive header is just for optional
> parameters describing the keep-alive.

I am under the impression that Jeff uses "Keepalive: myaddress" as a 
synonym to "Connection: Keep-alive my-addr" header, which should be 
interpreted as "keep-alive the connection to my-addr, if you can" 

	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 Saturday, 18 November 1995 02:14:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:36 EDT