W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997


From: Scott Lawrence <lawrence@agranat.com>
Date: Sat, 09 Aug 1997 21:56:19 -0400
Message-Id: <199708100156.VAA05242@devnix.agranat.com>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4133

>>>>> "JF" == John Franks <john@math.nwu.edu> writes:

JF> The version number design which you have promulgated since 1993 gets
JF> rehashed every six months because:

JF>   1) It is counterintuitive to the point of being confusing,

  That is a particularly subjective statement.  I find the version
  numbering rules as they stand now to be so obvious and intuitive
  that they hardly need discussion at all.  Reasonable people differ,
  but in this case the 'intuitive'ness is not (IMHO) a usefull

JF> It is specious to say that a 1.1 proxy can send a 1.0 version number
JF> because then it becomes a 1.0 proxy.  What is really happening is that
JF> the proxy is lying in its version header because that is the only way
JF> it can request the response it wants from the server.

  I fail to see the problem - if it wants a 1.0 response, it can send
  a 1.0 request; if it wants a 1.1 response it can send a 1.1 request.

JF> The reason that the version header comes up again and again is not
JF> that difficult to understand.  What implementors NEED to know in
JF> processing a transaction is the *version of that entity*, i.e. the
JF> lowest version number such that a client or proxy of that version can
JF> handle this entity.  The current version header gives only an upper
JF> bound estimate for this number. It is a non-trivial (and potentially
JF> error-prone) task to calculate this entity version.  If versions 1.x
JF> with x > 1 come into being this problem will get harder.

  This is simply not true by the specification - the responder is
  required to send a response which may be correctly interpreted by an
  implementation of the protocol version _in the request_.  The
  requestor need not use the version number in the response for
  _anything_; it knows what version it requested and can interpret the
  response by those rules.

JF> Apparently the original design intent was that the major version
JF> number would be the "entity version" and the minor number would
JF> indicate capability.  This is manifestly no longer the case.

  The intent was plainly nothing of the kind, as has been spelled out
  in this forum and various IETF documents repeatedly.

JF> There is substantial evidence that new implementors *expect* the
JF> version header of a response to contain the entity version (which they
JF> need and which the origin server knows) rather than a statement of
JF> capability.  When they discover this is not the case (either by
JF> reading the spec or when something breaks) they are annoyed by the
JF> extra work, seemingly gratuitously created for them, and they come
JF> here to complain.  This is unlikely to change anytime soon.

  It is true that we cannot protect ourselves from the complaints of
  developers who do not read the specification before they write thier
  bugs.  That is no reason to change anything at all.

JF> The bottom line, though, is that there are three pieces of version
JF> information related to an HTTP transaction: 1) the capability version
JF> of the sender, 2) the entity version of the transaction, and, for
JF> requests, 3) the requested version of the response.

  There is no such thing as the 'entity version of the response' and
  there is no need for any.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Saturday, 9 August 1997 19:00:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC