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: Mon, 11 Aug 1997 17:51:01 -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.970811172637.9274A-100000@hopf.math.nwu.edu>
On Mon, 11 Aug 1997, Klaus Weide wrote:

> On Mon, 11 Aug 1997, John Franks wrote:
> 
> > More formally, the entity version of a response is 1.N provided
> > every HTTP header or footer in the entity is defined in HTTP/1.N and
> > at least one header or footer in the entity 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.
> 
> Ok thanks, that's a start.
> 

You are correct that it depends on more than the entity headers.
It also depends on the response header and the general headers.
I don't really care what it is called. Let's call it a "response
version" for now.

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.  Each value and extension of each
header must be looked up in the table.  Whether this is "trivial" to
implement is a question I will leave to proxy implementors.  However,
as a server implementor, I can tell you that the response version is a
trivial byproduct of a server producing the response.

> > Given the entity:
> > 
> > 
> >    HTTP/1.1 200 OK
> >    Server: Blah
> >    Date: Mon, 11 Aug 1997 19:33:55 GMT
> >    Last-modified: Fri, 25 Jul 1997 13:43:15 GMT
> >    Content-type: text/html
> >    Content-length: 3052
> > 
> >    ...3052 bytes of stuff...
> > 
> > there is no way to tell if there is an implicit "Connection: close"
> > header (which there would be if the entity version is 1.0) or an
> > implict "Connection: keep-alive" (which there would be if the 
> > entity version is 1.1).  Thus in this case the entity version would
> > contain information not derivable from the entity alone.  In other
> > cases I think the entity version could, at least in principle, be
> > derived from the entity.  Am I wrong?
> 
> So your formal definition above has failed to describe what you mean.
> There is one thing which cannot be trivially derived from the message
> itself as given, and the definition does not account for it.
> 

But the definition *would* account for it if it were part of any HTTP
response header.  If it is never a part of any response header the 
question of what the definition accounts for is completely moot.  You
are picking nits.

> Anyway, the property of the response which you express as an implicit
> Connection token is unambiguously defined one way or the other, each
> time such a response message is received, by the version number in the
> status line.
> 

This is not correct.  It is not unambiguously defined by the the
version number of the response header (the "status line") as you
assert.  Perhaps you meant it was determined by the version number of
the request header in the request which elicited the response.  I am
not sure since the request header contains no "status".


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Monday, 11 August 1997 15:52:42 EDT

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