W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997


From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Sun, 10 Aug 1997 23:47:15 -0700
To: Klaus Weide <kweide@tezcat.com>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9708110007.aa10700@paris.ics.uci.edu>
>This shows that at least these two 1.0 proxies do not send their own
>version in a forwarded (OR cached) RESPONSE.
>Now for whether they downgrade the version to their own in a REQUEST -
>yes, they both do: (only shown for CERN/3.0)

Well, I guess that explains the confusion.  I have talked to the developers
several times and each time was assured that the proxy sent its own
version in the message.  It didn't occur to me that they would do one thing
on the request and a different thing on the response.  The *really*
boneheaded thing is I just checked Apache's proxy and it does the same
stupid thing, and I could have fixed that code myself.  *sigh*  That covers
just about every proxy, if we include Gauntlet as being broken both ways.

>The only harm I can see is with a HTTP 1.1 (or higher) client, which could
>be misled into believing that it is talking to a 1.1 proxy.  As a result
>it might attempt to use a 1.1-only feature in a later request through that
>proxy - for example sending a chunked request body in a POST.

I have a feeling that chunked requests will only be usable by specialized
applications.  A normal CGI script cannot accept chunked, because CGI/1.1
itself requires a Content-Length.

I hesitate to point out the effect it will have on the caching requirements.

I'm not too keen on relying on a connection kluge.  Given that the critical
parts of the versioning semantics are in the request chain and not (yet)
in the response chain, how about the following compromise:

   Follow the existing versioning requirements as-is, except that if the
   request is HTTP/1.0 (and only HTTP/1.0), then make the response HTTP/1.0.

That will allow for future extensions to the protocol in minor versions
beyond 1.1 to be protected, but avoid breakage with HTTP/1.0 proxies
and the occasionally idiotic client that pukes on HTTP/1.1.  It will
probably make Jeff happier as well, since it makes detecting an HTTP/1.0
cache much easier.

It also requires recycling the HTTP/1.1 specification as Proposed, but
that is just a procedural issue.

Received on Monday, 11 August 1997 00:10:21 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT