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

Re: Call for Closure - HTTP response version

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 31 Dec 1996 20:57:21 +0100 (MET)
Message-Id: <199612311957.UAA13676@wsooti04.win.tue.nl>
To: Dave Kristol <dmk@research.bell-labs.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2210
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

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

*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. 


> 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

Received on Tuesday, 31 December 1996 11:59:30 UTC

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