- From: Chuck Murcko <chuck@n2k.com>
- Date: Fri, 20 Dec 1996 18:14:00 -0500 (EST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
As I said in my reply to Dave, any resolution of this issue should be consistent with section 3.1 of RFC 1945: 3.1 HTTP Version HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. This seems to favor choice 2) below. Dave Kristol liltingly intones: > > I still consider the question unresolved as to what version an HTTP/1.x > server should return for an HTTP/1.0 request. I claim the draft > (section 6.1) does not specify it: > "The first line of a Response message is the Status-Line, > consisting of the protocol version followed by ..." > > To review (minus the pros and cons), the issue is whether the server > should return (1) HTTP/1.0 (the version of the request) or (2) HTTP/1.1 > (the version the server software understands). The concern people have > expressed is that in the first case you could never determine whether a > server understands HTTP/1.1. > > ...edited for brevity... > chuck Chuck Murcko N2K Inc. Wayne PA chuck@telebase.com And now, on a lighter note: Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it.
Received on Friday, 20 December 1996 15:16:29 UTC