Re: HTTP/1.1 & Proxies

At 03:22 AM 7/2/97 -0700, Josh Cohen wrote:
>> 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. 

This is the very issue I was trying to address.

[...]
>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
>not.
>
>This foils your scheme because the client wouldnt know that this
>proxy exists if there is another proxy between the client and it.
>
>ie
>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 )

I think this touches on the sort of idea I had in mind.  I was assuming
that there would be cooperation down the line, so it was not the sole
responsibility of the client to detect the 'unclean pipe'.

One specific thought I had was that each client/proxy agent could compare
the last entry in a server trail with the IP address which it had used to
access that proxy, and hence detect if the upstream proxy/server had added
to the trail.  If such an omission is detected then a <missing proxy> entry
might be added to the trail to warn downstream clients (and the HTTP
version number downgraded?).

There would be a *presumption* that any server/proxy that added a trail
entry claiming to be HTTP/1.1 (or whatever) would obey some defined set of
rules.

What I am trying to suggest, in broad terms, is a way of verifying a
communication chain to some level of functionality *without* requiring
cooperation from intervening legacy systems.  The SMTP community have
succeeded in this goal with ESMTP.  It may be that the discussions
regarding OPTIONS can lead to the same result.  I was trying to float
another conceivable approach.

GK.
---

------------
Graham Klyne
GK@ACM.ORG