Re: issue: what version?

Jeffrey Mogul <mogul@pa.dec.com> wrote:
  > [DMK:]
  >     2) Send HTTP/1.1 responses always.
  > 
  > 	Pro:	the server advertises its capability
  > 	Con:    because the response (headers) must be HTTP/1.0
  > 		compatible, the server is "lying" about the kind of
  > 		response and may mislead or confuse the client.
  > 
  > I don't understand this "Con".  As far as I remember, we have always
  > insisted that HTTP/1.1 responses be completely usable by HTTP/1.0
  > clients, providing that these clients follow the long-standing rule
  > that they should ignore headers that are not defined in the version
  > they purport to implement.  I don't think we changed the syntax or
  > semantics of any HTTP/1.0 response header (or request header, for
  > that matter).  If we did, it's possibly a bug in the spec.
  > 
  > So an HTTP/1.1 server ought to be able to send to an HTTP/1.0
  > client a response which is both fully compliant with the HTTP/1.1
  > spec, and also fully comprehensible to an HTTP/1.0 client.  (Of
  > course, it is possible to botch the server implementation, but
  > we usually design a spec on the assumption that its implementations
  > will actually implement it.)
  > 
  > Perhaps if someone has a specific example of a case where sending
  > an HTTP/1.1 response to an HTTP/1.0 client will cause a problem,
  > they should share it with the working group, before we attempt
  > to drag HTTP/1.1 from "Proposed" to "Draft".

My point about "lying" (which I knew to be a loaded word) is that,
because the response is an HTTP/1.0 response in every way, it's false
to call it HTTP/1.1.  (But then, we have to decide whether the version
refers to the message or the agent's capabilities, as Paul Hethmon
pointed out.)

On that point, the spec. is ambiguous (3.1):
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of
the protocol. The protocol versioning policy is intended to allow the
sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication.

In the current case, I claim the "format" is HTTP/1.0, but the
"capacity for understanding" is HTTP/1.1.

Anyway, here's what I think is an example of a possible problem:
Suppose an HTTP/1.0 UA sends Connection: keep-alive, and an
understanding HTTP/1.1 server responds:

HTTP/1.1 200 OK
Connection: keep-alive
...

Now, "keep-alive" is not a defined HTTP/1.1 connection token, and,
indeed, the HTTP/1.1 server is not keeping the connection alive in the
HTTP/1.1 way.  The server (as part of an HTTP/1.1 response) should have
no Connection response header.  (Yes, okay, the Connection: keep-alive
header the functional equivalent in an HTTP/1.1 response.)

Another example.  Suppose I have an HTTP/1.1 client that, for its own
reasons, sends an HTTP/1.0 request.  It gets back an HTTP/1.1 response
that contains no Connection response header.  Should it interpret the
HTTP/1.1 response to mean the connection is being kept open?

Dave Kristol

Received on Tuesday, 3 December 1996 12:26:26 UTC