- From: Scott Lawrence <lawrence@agranat.com>
- Date: Sun, 1 Mar 1998 10:18:10 -0500 (EST)
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: Larry Masinter <masinter@parc.xerox.com>, HTTP Working Group <http-wg@cuckoo.hpl.hp.com>, jg@w3.org, http-wg@hplb.hpl.hp.com
I wrote: > >> ... and section 3.1 spells out various rules about version number > >> usage, but does not specify that a server MUST send a 505 response > >> if it receives a major version number higher than the highest > >> version it implements. On Fri, 27 Feb 1998, Roy T. Fielding wrote: > That isn't why 505 was created. It allows a future server to deny > service to older protocols. Since we cannot know whether HTTP/2.0 > is incompatible with HTTP/1.1 (the major version change does not imply > incompatibility, it just removes the requirement for compatibility), > it is inappropriate for a server to be required to respond in error > to a message it might be able to respond to normally. That's why it > is not a MUST, and why Apache responds normally to an HTTP-version of > HTTP/2.0 if it can interpret the request as an HTTP/1.1 server. That logic does not seem sound to me - if changing the major version number means that the protocol _may_ be not backward compatible, then a recipient that does not implement 2.0 cannot know whether or not it can _correctly_ interpret the message as a 1.1 message. Your logic assumes that the authors of 2.0 will not make any semantic changes to existing protocol elements. The well-known problems with intermediate systems altering the response version also, I think, argue in favor of the more restrictive usage.
Received on Sunday, 1 March 1998 07:19:47 UTC