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: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Sat, 18 Nov 1995 21:30:57 -0800
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc: http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9511182131.aa29966@paris.ics.uci.edu>
>> 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.

Tunnel is defined in the lastest HTTP/1.0 specification (it is one of
the many definitions I added to explain some of the characteristics
of HTTP communication that is often ignored by implementors).
Use of a tunnel is compliant with HTTP, but requires that the HTTP
semantics not be changed by the presence of a tunnel.

Suffice it to say that IP addresses exist at (or below) the transport
level, and HTTP exists at the application level.  Using IP numbers
(or even hostnames) to define application-level behavior is wrong
because it won't work when the transport layer changes.  Therefore,
I try to avoid including them in the protocol when possible.

 ...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 Saturday, 18 November 1995 21:37:16 EST

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