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

Re: Server response version number

From: Larry Masinter <masinter@parc.xerox.com>
Date: Sun, 20 Oct 1996 21:09:42 PDT
To: frystyk@w3.org
Cc: jcma@ai.mit.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, w3c-http@w3.org
Message-Id: <96Oct20.210942pdt."2759"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1839
> 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.

Why bother downgrading? MAY downgrade, not SHOULD downgrade.

> 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".

You say "always" in the first sentence and then give conditions when
it doesn't hold in the second. That's confusing.

Perhaps you mean to say that a server SHOULD respond with the same
version as the request?

On a related issue, I'm concerned about the possibility that a single
server might 'downgrade' depending on the URL rather than the version
of the requestor: I think there are clients that presume the version
of subsequent responses based on the version of previous responses.
(The problem are CGI-generated headers, and the possibility of
shortcutting header-rewriting.) I think the issue of 'downgrading'
should explicitly prohibit this behavior.

Received on Sunday, 20 October 1996 21:15:46 UTC

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