- From: John Franks <john@math.nwu.edu>
- Date: Sun, 10 Aug 1997 09:36:16 -0500 (CDT)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Sun, 10 Aug 1997, Scott Lawrence wrote: > > The requestor has a version, and sends it (which may, at the > requestors option for whatever reason, be less than the highest > version it could use); the responder has a version and sends it, but > the response itself must always be valid according to the rules of > version sent by the requestor. What could be simpler? > Nothing could be simpler or more obvious! That is why a number of people have been arguing this is what the spec SHOULD say. Unfortunately, it says nothing of the kind and Scott like many people before him has been confused by it. There is already an entire RFC devoted to trying to explain the meaning of the version header precisely because the meaning isn't the "obvious" one. Let me quote: "An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. ... An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy." Thus, sadly, Scott's assertion "The requestor has a version, and sends it (which may, at the requestors option for whatever reason, be less than the highest version it could use)" is not true. The requestor can only send a lower version number if it knows the server is buggy. John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Sunday, 10 August 1997 07:37:21 UTC