- From: Jim Gettys <jg@pa.dec.com>
- Date: Thu, 12 Mar 1998 06:21:44 -0800
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: Scott Lawrence <lawrence@agranat.com>, Larry Masinter <masinter@parc.xerox.com>, HTTP Working Group <http-wg@cuckoo.hpl.hp.com>, jg@w3.org, http-wg@hplb.hpl.hp.com
> 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 > Subject: Re: 505 response a MUST? > > > 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 I think Roy is right on this one; I'm removing the change from Rev-03. - Jim
Received on Thursday, 12 March 1998 06:23:15 UTC