- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 31 Dec 1996 20:57:21 +0100 (MET)
- To: dmk@research.bell-labs.com (Dave Kristol)
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
Dave Kristol: > >Let me make some assumptions. They may be controversial, but I haven't >seen substantial contradictory evidence: > >1) The HTTP/1.1 draft is clear about which HTTP/1.1 headers cannot be >sent to HTTP/1.0 clients. > >2) If an HTTP/1.1 server sends a response labeled as HTTP/1.1, but with >only HTTP/1.0-compatible headers, HTTP/1.0 clients will understand >it. Ugh. I don't know what twist in this thread caused you to make those assumptions, but they paint a completely wrong picture of the actual situation. *ALL* headers are compatible, in a sense, with HTTP/1.0 clients, because HTTP/1.x clients ignore all headers they do not understand. Therefore, a 1.1 server can send as many HTTP/1.1 headers it wants to a 1.0 client, as long as it also includes enough 1.0 headers to let the client interpret the response correctly. Now, it is true that some HTTP/1.1 protocol *mechanisms*, like chunked encoding and 1xx responses, cannot be used with HTTP/1.0 clients. But mere headers can never break a 1.0 client. Example of a response which is compatible with both HTTP/1.0 and HTTP/1.1 clients: HTTP/1.1 200 OK Date: Tue, 11 Jun 1996 20:05:31 GMT <- 1.0 header Content-Type: text/html <- 1.0 header Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT <- 1.0 header Content-Length: 5327 <- 1.0 header Cache-control: max-age=604800 <- 1.1 header Content-Location: paper.html.en <- 1.1 header Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, {"paper.html.fr" 0.7 {type text/html} {language fr}}, {"paper.ps.en" 1.0 {type application/postscript} {language en}} <- not 1.0, not 1.1, but TCN header Etag: "gonkyyyy;1234" <- 1.1 header Vary: negotiate, accept, accept-language <- 1.1 header Expires: Thu, 01 Jan 1980 00:00:00 GMT <- 1.0 header The HTTP/1.0 specification tells you which headers you must include to let a HTTP/1.0 client correctly interpret your response. The HTTP/1.1 specification tells you which headers you must include to let a HTTP/1.1 client correctly interpret your response. If a HTTP/1.0 client gets a response with a HTTP/1.1 version number, it can safely discard all headers it does not understand and interpret the rest as HTTP/1.0. If the end result is not what the web site author intended, it is always the fault of the server, and never the fault of the client. [...] >Since no one has described a "show-stopper" scenario, I stipulate that >the choice of response version is not a threat to interoperation. Correct. > We >are left then with a choice based on protocol aesthetics or taste. Correct. Also, the 1.1 draft leaves this choice to the taste of the author of the server. I see no reason to change the draft to prescribe one particular choice. Though I completely agree with the sentiment that the draft needs more text explaining this issue. >Dave Kristol Koen.
Received on Tuesday, 31 December 1996 14:57:44 UTC