W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

HTTP version numbers returned by proxies

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 14 Jun 2007 12:48:22 +1200
Message-ID: <46709056.6040609@qbik.com>
To: HTTP Working Group <ietf-http-wg@w3.org>


Hi all

sorry, I did a search to see if I could find what I though I recalled as 
a previous discussion on this issue.

Basically there are sections of RFC2616 that require the HTTP version of 
an origin server's response to be known to various agents in a request 
chain.

Specifically RFC2616 has several areas which allude to either caches or 
clients or proxies maintaining a (temporary?) cache of the version 
numbers of origin servers for various reasons.

However, a proxy server that always responds with its own supported 
version number will break some of these mechanisms.

For instance, in caching, if you have several chained proxies, if an 
upstream proxy returns HTTP/1.1 for the response from an origin server 
that returned HTTP/1.0, then the downstream cache (to the proxy) cannot 
tell what the origin server's version was, and therefore has problems 
with things like the last sentence in RFC2616 S 13.9 (side-effects of 
GET and HEAD).

So, it would seem to me that a proxy shouldn't change the version number 
of the response from the origin server?  This then causes other 
problems, for instance if a client made an HTTP/1.1 request and the 
proxy would love to chunk the response back from an HTTP/1.0 server.

I understand there is an RFC on this - any pointers would be 
appreciated, we are trying to redesign our cache.  Supporting HTTP/1.1 
and 1.0 properly seems difficult.

Thanks

Adrien
Received on Thursday, 14 June 2007 00:48:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:10 GMT