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

Re: HTTP response version, again

From: David W. Morris <dwm@xpasc.com>
Date: Fri, 20 Dec 1996 16:11:16 -0800 (PST)
To: Larry Masinter <masinter@parc.xerox.com>
Cc: dmk@research.bell-labs.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.95.961220155950.2324A-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2146


On Fri, 20 Dec 1996, Larry Masinter wrote:

> Dave, what about:
> 
> # The protocol version in the response MAY be either HTTP/1.1 or
> # HTTP/1.0. The headers in the response MUST be consistent with BOTH the
> # protocol version of the response AND the protocol version in the
> # request.
> 
> I don't know why we have to nail this down. "We MAY not always have to
> MUST if we can MAY."

And the content of the response MUST be compatible with the request
version when the version is lower than the response version ...
this I suppose is a side effect of TRANSFER-ENCODING: as a header
not allowed by the above rule but is will surely break a 1.0 client
if it is presumed to ignore unknown headers and is sent a content
body with chunked encoding.

I think that the real issue here is we are using a single value to
accomplish two objectives:

   a.  Label the level of the response
   b.  Declare the capabilities of the server


Perhaps the 'bug' fix is to add a way for the server to declare its
capabilities ? And in the status, label the level of the response.

Dave Morris
Received on Friday, 20 December 1996 16:16:59 UTC

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