Subject: HTTP version numbers returned by proxies

From: Adrien de Croy <[email-masked]>
Date: Thu, 14 Jun 2007 12:48:22 +1200

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

---

From: Travis Snoozy <[email-masked]>
Date: Wed, 13 Jun 2007 17:58:21 -0700

On Thu, 14 Jun 2007 12:48:22 +1200, Adrien de Croy <[email-masked]>
wrote:

<snip>
> version number will break some of these mechanisms.
<snip>

That's why it's not allowed. Section 3.1:

  Proxy and gateway applications need to be careful when forwarding
  messages in protocol versions different from that of the application.
  Since the protocol version indicates the protocol capability of the
  sender, a proxy/gateway MUST NOT send a message with a version
  indicator which is greater than its actual version. If a higher
  version request is received, the proxy/gateway MUST either downgrade
  the request version, or respond with an error, or switch to tunnel
  behavior.

So, if you access an HTTP/1.1 server through a HTTP/1.0 proxy, sorry --
you're stuck with HTTP/1.0.

-- 
Travis

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 14 Jun 2007 13:05:39 +1200

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.

Adrien

---

From: Travis Snoozy <[email-masked]>
Date: Wed, 13 Jun 2007 18:19:00 -0700

On Thu, 14 Jun 2007 13:05:39 +1200, Adrien de Croy <[email-masked]>
wrote:

> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 13 Jun 2007 19:53:26 -0700

> you're stuck with HTTP/1.0.

No, the paragraph has nothing whatsoever to do with that, and
certainly doesn't require a least common denominator.

An HTTP sender always sends its own version number, even when it is
forwarding a message that originated in a different minor version.
[The only exceptions are for working around specific browser bugs.]
All HTTP/1.0 messages are HTTP/1.1 messages too.  Later versions can
also upgrade messages to their own supported protocol(s), if they
so desire -- the paragraph merely states that they cannot forward
messages with a higher version than they understand.

The versioning mechanisms in the specification are all based on the
possibility that there is a 1.0 sender in the chain -- they should
be read with that in mind.  Requiring message versions to be
downgraded for compatible protocols would have negated the need
for those mechanisms in the first place (at considerable cost).

....Roy

---

From: Jeffrey Mogul <[email-masked]>
Date: Mon, 18 Jun 2007 15:53:56 -0700

http://www.ietf.org/rfc/rfc2145.txt

There are references from RFC2616, section 3.1, to this document.
Perhaps these should be marked as normative; certainly, a proxy
implemention that violates RFC2145 is non-compliant in any reasonable
sense of the word.

-Jeff