- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 31 Dec 1996 20:57:21 +0100 (MET)
- To: Dave Kristol <dmk@research.bell-labs.com>
- 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 11:59:30 UTC