W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: Server response version number

From: John C. Mallery <jcma@ai.mit.edu>
Date: Mon, 21 Oct 1996 11:06:59 -0400
Message-Id: <v03007801ae9139a7f547@[]>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, w3c-http@w3.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1842
At 6:18 PM -0400 1996-10-20, Henrik Frystyk Nielsen wrote:
>>The WG would like a definitive statement from the implementors about
>>which option makes the most sense.
>As "one of the implementors" here is what I recommend as a practical solution:
>1) A client always sends a request using the latest version it supports.
>Only if the client already knows the version of the server and this version
>is inferrior to the version of the client, then it should downgrade to a
>version understood by the server.
>2) A server always responds with the same version as the request. Only if
>this version is not directly supported by the server, it should take the
>version that comes closest. If the semantics of the response requires a
>specific version and this is not the version of the client then it should
>return "505 HTTP Version not supported".


This is a statement of one way to handle the situation.

You are missing the design rationale for why one should use this approach
at all.

It would be most helpful to see a comprehensive analysis of all 1.1 and 1.0 methods
and proxy situations to see if downgrade is the best approach.

What are the reasons for the approach?  How do these reasons evolve
when new protocol versions come out? How much sense do they make when few
1.0 clients and servers remain?

If the downgrade approach is best, the spec should read MUST to ensure consistent
Received on Monday, 21 October 1996 08:15:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC