What is a "message version" (was Re: RE-VERSION)

On Tue, 12 Aug 1997, John Franks wrote:
> On Mon, 11 Aug 1997, Klaus Weide wrote:
> 
> > On Mon, 11 Aug 1997, John Franks wrote:
> > > On Mon, 11 Aug 1997, Klaus Weide wrote:
> > > 
> > > 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.
> > 
[ ... snipped liberally ... ]
> > That is something *quite* different than what you wrote before (and
> > above).  
> 
> No it isn't.

I probably don't understand what you mean by "defined in HTTP/1.X".
Your use of the word "defined" seems to need an explanation.

[ ... large cuts ... ]
> 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.

For the purpose of HTTP, "deflate" for Content-Encoding is defined in
RFC 2068 3.5 (by reference to other documents).  Why is one relevant
and the other isn't?  (Aside from the the fact that the header
Transfer-Encoding, itself, is only defined in HTTP/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.

Roy gave a list of 5 requirements a few days ago, extracted from RFC 2068,
and only 4 of them apply to responses (maybe now that's only 3 left,
if unsolicited "100 continue" is dead).  That doesn't look like much
work.  Or are there any other items which should be added to his list?

If you expect requirements to become drastically more difficult for
versions >1.1, could you give an example of the kinds of changes you
expect and how a proxy might be helped by an explicit "message version"?

But yes, a proxy must start over from scratch doing this "work", 
because all those are hop-by-hop questions.  A compliant 1.1 proxy also
has to be a compliant 1.1 server to its clients, so it has to be
responsible for generating only valid responses.  Is your sugggestion
about allowing a proxy to switch to tunnel behavior under certain
conditions?

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

I was trying to avoid yet another use of the word "entity"...

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

Yes.

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

In my reading that is what it DOES mean.  Searching through the text for
those strings, I found no place which required a different reading, other
than possibly the sentence you quote (below).  That sentence maybe should
be reformulated (I find the meaning unclear; maybe an implied "to a
HTTP 1.1 recipient" is missing).

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

I see no clear indication of that, but we could just ask them.

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

So far it is a vague concept in search of a definition.

Your last sentence points to the only practical appplication of this
concept which has been given so far (AFAIK) which might be useful.
(There may be others, see my question above re tunnel.)  You gave as an
example that a proxy may want to prevent getting chunked responses.
I don't know whether that would make the response a "1.0 message" since
the concept is not well defined.  But even if such a negotiation mechanism
were useful (maybe more so in the future, for some hypothetical feature of
HTTP/1.2),  it doesn't have to be phrased in terms of "message version".
A general mechanism to turn specific features on or off would be much more
useful than that, IMHO.


      Klaus

Received on Tuesday, 12 August 1997 11:38:05 UTC