Re: origin server vs. proxy with full URL

On Fri, 27 Dec 1996, John Franks wrote:

> I am still waiting for consensus on the response header from an 
> HTTP/1.1 server to an HTTP/1.0 request.  Did I miss it?

As far as I'm aware, you haven't. I don't think there's been one.

> The options were:
> 
> 1) Send HTTP/1.0 because that is the protocol the server is actually
> using.
> 
> 2) Send HTTP/1.1 to advertise the servers capability to use 1.1 even
> though what it is using is the 1.0 protocol.

Well, it's actually using both. Otherwise it wouldn't be right to
label it HTTP/1.1. It's using a subset of HTTP/1.1 that is compatble
with HTTP/1.0.

> 3) This is an implementation issue and up to the server.  The browser/proxy
> must be able to accomodate either.
>
> I believe Dave opted for 1) and that seems the most reasonable to me.
> The ambiguity has already created the notorious AOL flap.  Apparently
> the Apache writers decided on option 2) (eminently reasonable) and at
> least some of them interpreted the spec to mean that option 2) is a
> MUST (this seems hard to defend especially in light of the fact the WG
> can't agree on the meaning of the spec).  At the same time AOL proxy

Well, personally, I'm in favor of 3). I agree that the spec doesn't
say one way or the other, and (as an Apache writer), I personally
never interpreted the spec to say that 2) is a MUST, though I perfer
it.

> developers interpreted the HTTP/1.1 header to mean that HTTP/1.1
> protocol and headers were being used.  This is not really consistent
> with the current spec, but is a "common sense" interpretation one
> might arrive at if the spec was not carefully studied.  Yes, everyone
> SHOULD study the spec, but option 2) is somewhat counter-intuitive 
> and even the WG does not agree that this is what the spec says.

As near as I can tell, there are three ways 2) can be parsed by a
HTTP/1.0 client:

a) It can see the "HTTP/", decide that it's HTTP/1.0, and parse it as
such. Most browsers seem to do this (Netscape, etc...)

b) It can see "HTTP/1.1", and since it doesn't support HTTP/1.1, it
can return an error. The AOL proxies were doing that.

c) It can look for "HTTP/1.0", not find it, decide it's HTTP/0.9, and
treat it as such (displaying to the client the entire response,
incl. headers). There are some (very few) old browsers that do this,
and the AppletViewer in Sun's JDK (1.0.2 at least - it's also reported
to occur in Symantec's Cafe) does as well.

IMHO, an interpretation of a) is correct, c) is correct as well, but
pedantic, and b) is stupid (and wrong).

> The bottom line is that 2) is consistent with the spec and may even
> have been the intention of some spec authors.  But it is sufficiently
> counter-intuitive that it will continue to cause problems unless the
> spec spells out explicitly that this is what is required.  The fact
> that the WG can't agree on what the current spec says about this is
> prima facie evidence that ambiguity needs to be removed.

Or that it should remain ambiguous. As I've stated before, all I think
the spec needs to do is spell out what an HTTP browser/server needs to
do it it receives a message of a higher version that its own (namely,
treat it as a message of the highest version it understands with the
same major version number).

I think it's perfectly reasonable for both 1) and 2) to coexist.

I don't know if a decision will ever result in a consensus
(even a rough one), anyway. If this issue has to be decided, it may
only be decided by (cringe) a vote.

-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Received on Friday, 3 January 1997 15:10:08 UTC