Re: keepalives and proxies: a request and a proposal

>> 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/