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

Re: HTTP response version, again

From: Abigail <abigail@ny.fnx.com>
Date: Mon, 30 Dec 1996 11:27:01 -0500 (EST)
Message-Id: <199612301627.LAA06566@melgor.ny.fnx.com>
To: Steve Wingard <swingard@spyglass.com>
Cc: abigail@ny.fnx.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
You, Steve Wingard, wrote:
++ 
++ At 10:14 AM 12/30/96 -0500, Abigail wrote:
++ >
++ >I think the problem is more fundamental. If we force HTTP/1.0 clients
++ >to accept HTTP/1.1 reponses, they also have to accept HTTP/1.2,
++ >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.
++ 
++ Your conclusion doesn't follow.  An HTTP/1.x server should be aware of the
++ version number of the client that it is speaking to, and refrain from using
++ header information or mechanisms that are not "understood" by that client.
++ A response from an HTTP/1.1 server can be constructed to be acceptable
++ to an HTTP/1.0 client, and still be a "legal" HTTP/1.1 response.


In that case, it would be easy to put "HTTP/1.0" in the response as
well, wouldn't it? After all, if you 'downgrade' it to be HTTP/1.0, you
might as well label it as HTTP/1.0.

The problem is that if the server takes out headers that cannot be
understood by the client, but keeps HTTP/1.1 headers which can safely
be ignored by the client, but still labels it as HTTP/1.1, the client
doesn't know it can ignore those unknown headers.

In my opinion, the server should not include HTTP/1.1 headers which are
not part of HTTP/1.0 when responding to a HTTP/1.0 request, and label
the response as being HTTP/1.0.


Abigail
Received on Monday, 30 December 1996 08:29:15 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:20 EDT