Tokens for requesting/indicating upgrade

[I've split my responses into two - one to address the upgrade tokens
question and another to respond to proxy issues -SDL]

> From: Roy T. Fielding
> Subject: Re: Comments on HTTP TLS Upgrade draft

Henrik says:

> >Unfortunately this leads easily to an explosion of tokens that have to be
> >registered. HTTP doesn't have to say anything about the relationship
> >between the various tokens in the upgrade header field. It is sufficient
> >for the protocols (or sub protocols) independently to define how they can
> >interact with other protocols.

While I prefer having the Upgrade response indicate an ordered list
specifying the stack, I don't agree that HTTP doesn't have to say anything.
If I specify:

  Upgrade: CompressLayer/1.0, MuxLayer/1.1, HTTP/1.1

it certainly isn't the same as:

  Upgrade: MuxLayer/1.1, CompressLayer/1.0, HTTP/1.1

and the client needs to know which I mean.  This is a difference between the
usage (as I understand it) of the Upgrade header in a request and a
response - the request doesn't specify a stack, it specifies a set of
choices (without indicating which combinations are possible - a problem, I
think), but in a response it specifies an ordered stack.

> I agree with Henrik.  And I don't see anything vague about the definition
> of Upgrade in RFC 2616 -- the answer to this question is in the very first
> sentence.

I actually prefer the multiple-token solution, myself.  One point I thought
would cause confusion was the sentence (from 2616#14.42):

   The Upgrade header field only applies to switching application-layer
   protocols upon the existing transport-layer connection.

We are actually using it to insert a new layer into the stack, not change
the application layer protocol (indeed, in the IPP case we are treating both
TLS and HTTP as session layer protocols, but...).

> As for using the extension stuff, Upgrade is intended to be a simple
> switching mechanism for the immediate connection, in contrast to the
> various general extension mechanisms.  The two may or may not be used
> in tandem, or separately, but must not be co-dependent in their
> definition.
> Upgrade uses only the protocol tokens --- all further negotiation is
> postponed until after the protocol is switched.  Anything more complex
> than that can and should be accomplished via the extension mechanism,
> though I have yet to see any real need for further complexity which
> wasn't better accomplished by an extra round-trip -- complex things
> should not expect to be as efficient as simple things.

I agree, which is why I didn't want to include even hints in the upgrade
response about TLS/SSL options.

I'm perfectly happy to change the text back to a multiple-token rather than
combined-token [Rohit?].

--
Scott Lawrence           Director of R & D        <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/

Received on Monday, 2 August 1999 05:47:14 UTC