- From: Gregory J. Woodhouse <gjw@wnetc.com>
- Date: Tue, 31 Dec 1996 08:42:33 -0800 (PST)
- To: Simon Spero <ses@tipper.oit.unc.edu>
- Cc: www-talk@www10.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Tue, 31 Dec 1996, Simon Spero wrote: > On Mon, 30 Dec 1996, sameer wrote: > > > > HTTP/1.7, etc responses. That of course means no HTTP/1.x header can > > > ever contain something which causes problems with HTTP/1.0 clients. > > That's correct. That *is* why it's called HTTP/1.x, and not > > HTTP/2.x > > This is indeed the design goal; if there are any situations which > violate this constraint in such a way as to return incorrect results > without signalling an error, the specification is in error, and must be > corrected before being advanced. > And I don't think anyone is questioning that this behavior is correct. > If there are such cases, then there needs to be some emergency repairs; > if there are no such cases, the following is always safe, and will always > use 1.1 when available: > > 1) clients which support HTTP/1.1 SHOULD send 1.1 requests > Agreed. > 2) servers should echo the lesser of the request version and the > supported protocol version. > > Otherwise, I call for a coin flip. > > Simon > I'm a little unsure about this one, but I wouldn't object. Anyway, my only point has been that the document is ambiguous about the function of the version number in the response. I also have my doubts as to whether it is good design to use this version number to advertize the servers capabilities--and as I've indicated, this was not my reading of the spec, but I do admit this is one possible interpretation. --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one.
Received on Tuesday, 31 December 1996 08:52:50 UTC