Re: RE-VERSION

On Mon, 11 Aug 1997, John Franks wrote:
> On Mon, 11 Aug 1997, Klaus Weide wrote:
> > On Mon, 11 Aug 1997, John Franks wrote:
> > 
> 
> 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.  

That is something *quite* different than what you wrote before (and
above).  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?

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

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.

[ snipped exchange about imaginary connection: close ]
> > 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.

No, it seems I really don't understand what you mean.
That last peragraph is incomprehensible to me (except for the last
sentence :) )

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

Actually I should have said "unambiguously defined by the version number
in the status line together with the version number which was used in the
request".  Meaning that if the version in the staus line is 1.0, then
connection: close is implied.

 ---

So far this has been a completely theoretical conversation about
nonexistent things.  But, if I understand this much correctly, you are
proposing some new kind of header field ("Response-Version:" ?).
If and when somebody actually tries to write this down as an RFC-usable
algorithm, it'll hopefully become clear whether it is totally useless
or a really great thing.

     Klaus

Received on Monday, 11 August 1997 21:00:58 UTC