[10510] in www-talk@info.cern.ch
Re: Call for Closure - HTTP response version
daemon@ATHENA.MIT.EDU (Gregory J. Woodhouse)
Tue Dec 31 12:03:50 1996
Date: Tue, 31 Dec 1996 08:42:33 -0800 (PST)
From: "Gregory J. Woodhouse" <gjw@wnetc.com>
To: Simon Spero <ses@tipper.oit.unc.edu>
Cc: www-talk@www10.w3.org, http-wg@cuckoo.hpl.hp.com
In-Reply-To: <Pine.SUN.3.91.961231084416.8550A-100000@tipper.oit.unc.edu>
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.
