Re: HTTP/1.1 & Proxies

> Nasty!
Yes.. it is.

> This is probably 'closing the stable door after the horse has bolted' (HTTP
> 1.1 now being a published spec), but it occurs to me that an trail of
> proxies between client and origin server, similar to RECEIVED headers in
> RFC822 mail messages, might allow the client to determine the reliability
> of the HTTP 1.1 path.  I posit that each entry in the trail would contain
> host name, HTTP version number and server implementation and version
> identification (e.g. "WWW.ACME.COM, HTTP/1.1 (MoonSoft HTTPD V3.28)")
> This assumes that legacy proxies in the path which don't add this
> information can be detected, which I think should be possible.
Unfortunately, its common that the current proxies dont insert
any header. 
josh@birdcage>telnet w3proxy 8080
Connected to
Escape character is '^]'.
HTTP/1.0 200 OK
Date: Wed, 02 Jul 1997 10:17:55 GMT
Server: Apache/1.1.3
Content-type: text/plain
Content-length: 2
Last-modified: Wed, 02 Jul 1997 00:22:49 GMT
Connection closed by foreign host.

If there was a cache hit, there usually is a 'proxy-agent' header
(from our proxy), but in this case, an origin retreive, there was

This foils your scheme because the client wouldnt know that this
proxy exists if there is another proxy between the client and it.

client -> 1.1proxy -> 1.0proxy -> webserver

At least if the proxies propogated the OPTIONS request
down the proxy chain, a 1.0 proxy would report an error
and a 1.1 proxy not supporting the requested feature/spec
would reply accordingly.
( the client can detect the ;unclean; pipe )

> GK.

Josh Cohen				        Netscape Communications Corp.
Netscape Fire Department	               	       #include<disclaimer.h>
Server Engineering             

Received on Wednesday, 2 July 1997 03:27:49 UTC