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

Re: Proxies and loops

From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Date: Mon, 27 Nov 1995 20:58:12 +0100 (MET)
Message-Id: <199511271958.UAA02871@labinfo.iet.unipi.it>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> When I first read your proposal for a TTL field, I had the same
> reaction that Roy seems to have had: this isn't really necessary.
> The Forwarded: header allows any proxy to detect loops through
> itself, and can support that task without being mandatory.
> And do we have any evidence that forwarding loops are a real problem?
> Routing loops occur because our routing protocols are automatic and
> dynamic, and so can do stupid things rapidly and for transient periods.
> HTTP forwarding loops, on the other hand, would be created by humans
> and should thus be both less frequent and less transient.

At the moment this is true, but one might try to use some protocol
for the automatic configuration of proxies -- actually, caches (as
a matter of fact, I am investigating on this subject).  It might
be a bad idea or not, I cannot say at the moment.

What I know for sure is that it is very easy *now* to point a proxy
to another proxy, (e.g. in CERN code) without even thinking of the
problem of loops. You might not necessarily see the loop immediately,
perhaps much later when a particular request triggers the loop.

Certainly loops would be less frequent and less transient. The
latter makes the problem perhaps easier to trace, but harder to
remove on saturday nights. Especially on our side of the ocean, I

> I'm also not that worried about arbitrarily long forwarding paths
> (what's the harm?), and I would be worried about
>     o   the danger that some browser would set the TTL too short,
> 	thus causing hard-to-debug service problems

:) this makes me remember our microvax 3500 running an old version of
Ultrix (2.1 ?) where the TTL was limited to some low value, and it
couldn't communicate with some nodes...

>     o	the overhead of managing yet another mandatory header field on
>         every request, just to avoid a very rare problem.

actually I thought of including the TTL as an additional parameter
in the request header, right after the protocol.

> However: after I thought about this some more, I realized that there
> is an entirely different reason to include a TTL header in HTTP.

Two motivations are better than one...

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 Monday, 27 November 1995 12:04:44 UTC

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