- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 03 Dec 96 10:17:18 PST
- To: Dave Kristol <dmk@research.bell-labs.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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".
-Jeff
Received on Tuesday, 3 December 1996 10:35:25 UTC