Re: HTTP version number for 1.1 -> 1.0 responses

John Franks wrote:

> All of the arguments in favor of 2) which I have seen presented here
> are of the form: It doesn't break anything or doesn't break much or it
> only impacts broken clients.  I am willing to stipulate any of these.
> What I don't understand is what is the function of 2)?  The only
> situation where 1) and 2) differ is a 1.1 server talking to a 1.0
> client or proxy.  In this situation if the server sends a 1.1 version
> number that information is never usable by the client or proxy.
> Am I missing the point of 2)?  If so what is it?

Well, there could have been one, but it's not in the dr^H^HRFC, I think.
Historiaclly, widely used servers were always one step ahead from widely
used clients wrt HTTP implementation. Right now, HTTP/1.1 servers exist,
but there is no 1.1 client[1], as far as I know. I'd expect clients
to upgrade slowly, but they can't advertise themselves as 1.1 until
they fulfill all MUSTs from the spec and server can't know their exact
capabilities. If there was a dedicated header for advertising new
features, a client could say something like:

I-Can-Handle: Vary, 300, 205

and the server could use the features. In the example above, numbers indicate
status codes that the client can handle according to the specification
for the HTTP version which the server returns. 300 is included because
there are lots of HTTP/1.0 clients which can't handle it, so it's
indication that the client doesn't have that particular "common bug".

Values which don't start with number are HTTP headers that the client
can understand as per definition of HTTP version which server advertises.
Very seems very important to me because there is no way for proxy to
advertise that capability unless it implements all of HTTP/1.1. And this
particular 1.1 feature is more important for proxy than any other, if you
ask me.

Can the client send I-Can-Handle before it knows server's HTTP version[2]?
There could be upgrades and some kind of version information is needed.
One possibility is adding parameters to header values. Than we have:

I-Can-Handle: Vary; v=1.1, 300; v=1.2, 205; v=1.1

Major number can probably be left out, and perhaps there should be some
way to indicate upgrades from drafts and/or RFCs that accompany HTTP/1.1

I think I should stop here. I don't intend to write an Internet draft.

[1] To be honest, there is one HTTP/1.1 client, but I think it's not used
    much.

[2] Determining HTTP version that applies to the particular resource is
    a problem. Imagine HTTP/1.1 server with HTTP/1.0 CGIs or something like
    that.

> Would the advocates of option 2)
> recommend that a HTTP/2.3 server put HTTP/2.3 in the response header
> sent to a 1.0 client?

No, the change in major number means there is incompatible change. If the
server can talk HTTP/1.x, it should reply with the highest 1.x version
it knows about, for example HTTP/1.7.

-- 
Life is a sexually transmitted disease.

dave@fly.cc.fer.hr
dave@zemris.fer.hr

Received on Saturday, 4 January 1997 01:49:17 UTC