W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: HTTP/1.1 & Proxies

From: Graham Klyne <GK@acm.org>
Date: Wed, 02 Jul 1997 12:53:00 +0100
Message-Id: <>
To: Josh Cohen <josh@netscape.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3617
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
>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 )

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

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.


Graham Klyne
Received on Wednesday, 2 July 1997 04:56:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:02 UTC