Re: HTTP version number

Roy T. Fielding:
>
>No conversion occurs within the same major version number.
>In fact, that is the main distinguisher between the major and
>minor version changes.  

OK, I just re-read Section 3.1, and I see now where my interpretation
was wrong.  The correct interpretation makes me just as uneasy,
though.

>Any 1.x proxy can safely forward any
>1.x request or response without changing anything except
>the Request-Line/Status-Line (it always sends its own native version)
>and the Connection, Forwarded, and Host header fields.

I don't see immediately why Connection, Forwarded, and Host would be
special, but never mind that now, I will worry about such details in
April.

I guess the HTTP/1.1 spec will need a long section about
interoperating with 1.0 applications.

General comments on section 3.1:

1) Is there any rationale for the rules in Section 3.1?  

2) I'm not sure that I really like the weak requirements for
translation by proxies that are in the draft spec now: these
requirements will basically shift the burden of making things
interoperable from proxy authors to httpd and CGI authors, and there
are a lot more CGI authors than proxy authors.

3) With proxies being allowed to upgrade and downgrade the minor
version number, it seems that the server, it it gets a 1.1 request,
will not be able to find out if there are any 1.0 applications in the
request chain.

4) So the server has to make things interoperable, but it does not
even know the capabilities (versions) of the software it is serving
to!  So, for example, if the server uses a 1.1 Cache-Control header,
it must always include a 1.0 Expires header.

5) Wouldn't things be easier if we did a major version number change
and defined HTTP/2.0 instead of HTTP/1.1?

6) In summary, I suspect that the version rules will need to be
seriously reviewed.

I want to propose adding the issue "version rules in Section 3.1" to
the HTTP/1.1 issues list.

> ...Roy T. Fielding

Koen.

Received on Tuesday, 5 March 1996 15:20:22 UTC