W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Re: Call for Closure - HTTP response version

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 31 Dec 1996 16:52:24 -0800 (PST)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.GSO.3.95.961231164437.27146B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2216

On Tue, 31 Dec 1996, Foteos Macrides wrote:

> 	Clients may be (in fact, are) implementing HTTP/1.1 incrementally,
> and thus may support some HTTP/1.1 features, but still be declaring
> themselves as HTTP/1.0.  It most certainly is helpful for their
> development to receive the HTTP/1.1 headers.  Such clients also may be
> sending some of the HTTP/1.1 headers, if they're relevant to the
> features they handle, and don't result in things they can't yet handle.

There is nothing to stop use of HTTP/1.1 headers or mechanisms in 
a response to any HTTP/1.0 request as long as the ignore unknown
headers rule will keep the 1.0 client from being confused. 

I continue to believe that a response which conforms to HTTP/1.0 
should be labeled as being an HTTP/1.0 response. That it happens to
have additional useful headers unknown to HTTP/1.0 doesn't make it
anything but a HTTP/1.0 response.

As neither the client nor the server author, but rather a network
administrator in the middle, I would find it much more precise to
see a server I knew to be HTTP/1.1 capable returning a HTTP/1.0
status in response to a HTTP/1.0 request because that would hint to
me that the server knew it was downgrading the response. If the 
status is HTTP/1.1 it would suggest that the server might not have
noticed the request to be 1.0

Truth is labeling!

Dave Morris
Received on Tuesday, 31 December 1996 16:57:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC