- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 03 Mar 97 18:10:23 PST
- To: Cary Timar <cctimar@mtnlake.com>
- Cc: http-wg@cuckoo.hpl.hp.com
Thanks for commenting on this draft. I was just about to start working on some revisions when your message arrived. In case nobody has mentioned this already, in Section 2.3, Paragraph 4, Line 3, (on Page 4) > whose major version is equal to the one received in the request. Actually, that's page 5; the page numbers are at the bottom of each page. The form-feeds seem to have disappeared. The complete text here is: An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. Cary writes: The word "equal" should be replaced by "no greater than." The words, "highest version," earlier in the sentence, guarantee that this will be equal, when this is possible. However, the current wording leaves no option available to a server which is not even conditionally compliant with any version whose major version is equal to the one received in the request. I'd accept this change; the paragraph becomes: An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request. Cary also writes: If the 2.1 server receives a 3.x request, it should also return a status 505 (or the version 2 equivalent). The client can then be expected to note the response and repeat its request using a 2.x (or 1.x) protocol. I've been informed that Apache, which is the most popular server on the Internet today (and thus represents a significant installed base) apparently will accept a request using any version number, if it can parse the rest of the headers. I verified this with www.apache.org, which seems to accept GET / HTTP/9.93 Host: www.apache.org (if the version number is >= 1.1, it insists on the Host header). Maybe this isn't the right behavior, but I sense a lack of consensus here, so I left this as a MAY rather than a SHOULD (or MUST) for now. Clients should use the same approach, with appropriate alterations. A client should never receive a response whose version number is higher than the one it implements, because a server is not supposed to send a response whose version is higher than the one in the request, and a client "MUST NOT send a version for which it is not at least conditionally compliant." As a side note, the ability to support 1.0 should be required in all future compliant servers and clients, until version 1.x is long obsolete (at which point some higher minimum could replace it). This would ensure that the protocol version negotiation will end somewhere (consider a negotiation between a client and server that have no common version they both comply with, because the extra code was trimmed out to minimize the footprint). I'm not sure this is something we can legislate, in part because I don't see any way of setting a cutoff date in a specification (other than "forever"). The last time we tried a firm cutoff date, the Internet was a lot smaller. I still have the button I was given then: "I Survived the TCP Transition 1/1/83"; as long as the people who ran that transition are still prominent in the IETF, I don't think that kind of cutover will happen again. I would have said "on the other hand, no rational server operator would voluntarily lock out a large chunk of the client base" ... but then I remembered all of those HTML pages marked "Enhanced for use with Lynx 3.0" (or whatever browser that was; I forget). -Jeff
Received on Monday, 3 March 1997 18:20:02 UTC