- From: Abigail <abigail@ny.fnx.com>
- Date: Mon, 30 Dec 1996 11:27:01 -0500 (EST)
- 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 UTC