W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Re: Call for Closure - HTTP response version

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
Message-Id: <Pine.SGI.3.95.961231083557.8869B-100000@shellx.best.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2207
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

> 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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC