Re: HTTP version numbers returned by proxies

On Thu, 14 Jun 2007 13:05:39 +1200, Adrien de Croy <adrien@qbik.com>
wrote:

> 
> 
> Hi
> 
> soprry if I wasn't clear, I'm actually talking about case where
> 
> HTTP/1.1 client sends HTTP/1.1 request to HTTP/1.1 proxy, which sends 
> request through another HTTP/1.1 proxy which goes then to an HTTP/1.0 
> origin server.
>
> the client and first proxy will receive an HTTP/1.1 response from the 
> proxy closest to the origin server (if it replies with its own
> version).
> 
> this means the client and first proxy do not learn the true version
> of the origin server.

Well, that's simple enough:

  We note one exception to this rule: since some applications have
  traditionally used GETs and HEADs with query URLs (those containing a
  "?" in the rel_path part) to perform operations with significant side
  effects, caches MUST NOT treat responses to such URIs as fresh unless
  the server provides an explicit expiration time.

The last proxy knows the origin server is 1.0. Therefore, the last
proxy should (must?) not set an explicit expiration time on the
content, and the content will not be cacheable downstream.

There's the other case, too:

1.1 client -> 1.1 proxy (A) -> 1.0 proxy (B) -> 1.1 server.

* Client requests http://example.org/?foo=bar
* A always requests http://example.org/?foo=bar from B (it's not
cacheable, presumably because B did not explicitly mark it as cacheable)
* B requests http://example.org/?foo=bar from the origin server

There was no win for caching, but nothing _broke_. All A cares about is
the fact that it's talking to B with HTTP/1.0 -- what the origin server
is speaking is irrelevant.

Nothing should care about what the origin server speaks -- only what
the "next guy" speaks.


-- 
Travis

Received on Thursday, 14 June 2007 01:19:04 UTC