- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Sun, 01 Mar 1998 22:30:52 -0800
- To: Scott Lawrence <lawrence@agranat.com>
- 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
> 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. No, it assumes a client won't send a 2.0 message to a 1.x server unless the 2.0 message is sufficiently semantically and syntactically compatible such that there is some reasonable assurance that the 1.x server will respond in an anticipated (and safe) manner, even if that means a 400 response. Forcing a server to respond in error just for the sake of an error only guarantees the worst-case behavior of an extra round-trip, and offers no extra safety in any case because deployed HTTP/1.x servers will never respond with 505. That code is intended for future 2.x servers to say "piss-off" to older clients in the format of an HTTP/1.1 message, since they will have to respond in the same major version as the old client. ....Roy
Received on Sunday, 1 March 1998 22:34:47 UTC