- 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
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