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

Re: RE-VERSION

From: John Franks <john@math.nwu.edu>
Date: Tue, 12 Aug 1997 08:04:33 -0500 (CDT)
To: Klaus Weide <kweide@tezcat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.96.970812070256.9867A-100000@hopf.math.nwu.edu>
On Mon, 11 Aug 1997, Klaus Weide wrote:

> On Mon, 11 Aug 1997, John Franks wrote:
> > On Mon, 11 Aug 1997, Klaus Weide wrote:
> > 
> > A revised formal definition:
> > 
> > The response version of a response is 1.N provided
> > every HTTP header or footer in the response is defined in HTTP/1.N and
> > at least one header or footer in the response is not defined in
> > HTTP/1.(N-1).  For the purposes of this definition a header is
> > an HTTP header provided it is defined in HTTP/1.X for some X.
> > 
> > > Now it remains to be shown for what this would be useful.  (It also
> > > remains to be seen whether Josh agrees with your definition :) )
> > > 
> > > As given by your formal definition, the "entity version" (which should be
> > > cassed something else, see below) can be trivially derived from the
> > > message.  It just requires tables of all headers defined by the various
> > > protocol versions, nothing else.  Therefore it is totally redundant.
> > 
> > It requires tables of all general, response and entity headers and all
> > possible values and extensions of those headers and the version of
> > HTTP which defines each of them.  
> 
> That is something *quite* different than what you wrote before (and
> above).  

No it isn't.

> I really understood that you were talking about just the
> presence or absense or a header field.  True, it didn't make much
> sense.  But does it make more sense by looking at all possible values
> and extensions?
> 
> 
> This requires that for every token your server may put in a header, it
> has to have the "first-appeared-in-version-1.X" information.  So for
> example if the server sends a "Content-Encoding: gzip" header, that
> doesn't make the "response version" 1.1; but if the server sends
> "Content-Encoding: deflate", it makes the "response version" 1.1.
> I wouldn't call that trivial.  I would call it absurd.
> 

Is this a troll?  Or do you seriously not understand.  Neither gzip
nor deflate is *defined* in any version of HTTP of which I am aware.
Neither affects the message version.  By contrast the header value
"chunked" for Transfer-encoding is defined in HTTP/1.1.  Its presence
makes the message version (at least) 1.1.

The work done by the 1.1 server *must* be done to construct valid
responses for both 1.0 and 1.1 clients.  The issue being discussed
is must a proxy start over from scratch in doing this work.
The present spec requires a proxy to start over from scratch.
I question the wisdom of that.

> 
> So far this has been a completely theoretical conversation about
> nonexistent things.

One can argue over whether message version in HTTP is a "thing" but it
certainly exists.  It may not be adequately defined.  I think it isn't
and that is why I made an attempt at offering a definition.  I know
that Roy is fond of repeating that no message version exists beyond the
major version number but this inconsistent with
draft-ietf-http-v11-spec-08.

That specification uses the terms "HTTP/1.1 message" and
"HTTP/1.1 request" numerous times and uses "HTTP/1.0 request"
once.  The meaning of this document would certainly be changed
if all occurences of 1.0 and 1.1 in these phrases were changed
to 1.X.  

It might be useful to clarify what "HTTP/1.1 message" means as used in
the spec.  But I believe that one thing it does NOT mean is any
message generated by a 1.1 application and containing a 1.1 version
header.  If that were the meaning then the sentence

   "Persistent connections are the default for HTTP/1.1 messages,"

for example, would be false.  There are other uses of the phrase
"HTTP/1.1 message" in normative prescriptions using MUST and SHOULD,
which I don't believe the authors intended to apply to a message
sent from a 1.1 application to a 1.0 application.

So we could define the "message version" to be 1.1 if the message
is an HTTP/1.1 message as specified in draft-ietf-http-v11-spec-08.
More generally I suppose the message version of an HTTP/1.N message
is 1.N.  But I don't find that enlightening.

In my opinion, it is precisely because we have tried to avoid defining
what a 1.1 message version is (or equivalently, if you prefer, what an
HTTP/1.1 message is) that the version issue has confused so many
people.  It must be nearly impossible to write an HTTP/1.1 application
without at least conceptualizing an "HTTP/1.1 message".  The spec
authors seemed to have had the concept. In my view we would be much
better off in terms of robustness and probably also efficiency if we
carefully defined it and if applications communicated the fact that
they were sending a 1.0 or 1.1 message.  It would also be nice if
proxies could request any version which the server is capable of
generating.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Tuesday, 12 August 1997 06:07:20 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT