- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Sat, 30 Oct 1999 23:25:50 -0700
- To: Vinit Kumar <kumar_vinit@hotmail.com>
- cc: http-wg@hplb.hpl.hp.com
>For tunnels that are activated by a proxy request, A browser has to be
>configured to go through the proxy.So a request from a browser to a HTTP
>Proxy or a HTTP tunnel(activated by a request) is one and the same.
No, they aren't. The terms "client", "server", "proxy", "tunnel", etc.,
are all regarding the ROLE of the software for a particular request/response.
The first request went to a proxy -- after the 200 response, it is no
longer a proxy. It is not an HTTP tunnel -- it is just a tunnel, period.
>What I
>mean is that, even if the intermediary is a HTTP tunnel, the client always
>talks to the tunnel thru one part of the connection and a tunnel will
>forward that on another connection to the ORIGIN SERVER. Even the origin
>servers response will come to the intermediate tunnel which get forwarded to
>the client on the other connection.
>
>These requests or the responses MAY contain some hop-by-hop header
>information such as Keep-Alive, Connection Header (close), Max-Forwards
>etc.. While a proxy can take care of them ,what will a should a HTTP tunnel
>do? A http tunnel would'nt even look at the response or at the request(apart
>from looking at the URL to see where the forwarding connection should be
>established).
>
>How does a HTTP tunnel take care of persistant connections and request
>pipelining?
RFC 2616:
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.
By definition, it does not grok HTTP, therefore it doesn't take care
of persistant connections and request pipelining.
....Roy
Received on Saturday, 30 October 1999 23:29:39 UTC