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

Re: issue: what version?

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 03 Dec 96 10:17:18 PST
Message-Id: <9612031817.AA28595@acetes.pa.dec.com>
To: Dave Kristol <dmk@research.bell-labs.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2019
    2) Send HTTP/1.1 responses always.

	Pro:	the server advertises its capability
	Con:    because the response (headers) must be HTTP/1.0
		compatible, the server is "lying" about the kind of
		response and may mislead or confuse the client.

I don't understand this "Con".  As far as I remember, we have always
insisted that HTTP/1.1 responses be completely usable by HTTP/1.0
clients, providing that these clients follow the long-standing rule
that they should ignore headers that are not defined in the version
they purport to implement.  I don't think we changed the syntax or
semantics of any HTTP/1.0 response header (or request header, for
that matter).  If we did, it's possibly a bug in the spec.

So an HTTP/1.1 server ought to be able to send to an HTTP/1.0
client a response which is both fully compliant with the HTTP/1.1
spec, and also fully comprehensible to an HTTP/1.0 client.  (Of
course, it is possible to botch the server implementation, but
we usually design a spec on the assumption that its implementations
will actually implement it.)

Perhaps if someone has a specific example of a case where sending
an HTTP/1.1 response to an HTTP/1.0 client will cause a problem,
they should share it with the working group, before we attempt
to drag HTTP/1.1 from "Proposed" to "Draft".

Received on Tuesday, 3 December 1996 10:35:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC