- From: John Franks <john@math.nwu.edu>
- Date: Fri, 8 Aug 1997 07:59:53 -0500 (CDT)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: Josh Cohen <josh@netscape.com>, HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Thu, 7 Aug 1997, David W. Morris wrote: > > Josh's #2 prefered choice matches my position ... I wouldn't mind if > a header were added to label the characteristics of the origin server. > Only required if the response level is less than the server's > ability. Possibly not terribly useful. > I agree completely. It always made more sense for the version number to reflect the response rather than the capabilities of the server. During the "contentious" discussion two arguments were made for sending the highest version of which the server is capable. Neither made much sense to me: 1) This is the way it was planned when HTTP/1.0 was created; and 2) An HTTP/1.1 client might choose to lie and say it is 1.0 if it thinks it is talking to a 1.0 server and then if the server is really 1.1 the client will never know unless the server returns the highest version of which it is capable. Actually, I think the original intent was that a 1.0 client should be able to read a 1.1 response and function properly by ignoring anything it didn't understand. Of course, chunking makes this fail spectacularly. As a final observation I would point out that a single program can be a server for multiple protocols. (In fact a few years ago I wrote a combination gopher/http server.) Thus a single program could be both an HTTP/1.0 and an HTTP/1.1 server each part complying with the relevant specification. Which "virtual protocol" is used would depend on the request version header. This seems to me to be completely compatible with both HTTP/1.0 and HTTP/1.1 specs and functionally equivalent to Josh's #2 choice (i.e version number represents response version). John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Friday, 8 August 1997 06:03:41 UTC