- 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