Re: Comments on HTTP TLS Upgrade draft

>>We considered this alternative at some length, and at one point had
>>written the draft that way.  We liked the idea of the Upgrade response
>>header being able to specify a series of protocol tokens so as to
>>specify a stack to be used after the change.  We were not sure that
>>this would be understood, however.  RFC 2616 is vague on just what
>>multiple tokens could mean in an Upgrade response.  We elected for the
>>simpler set of expectations.
>
>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. For example, it can be stated in the
>registration of the SSL upgrade token that it can work with any version of
>HTTP.

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.

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.

>>> The response could of course still be a 101 Switching Protocols which
>>would
>>> then be propagated all the way back to the user agent and all
>>> intermediaries will already be in tunnel mode.
>>
>>But will they be expecting to stay there for all subsequent requests,
>>or will they just switch to tunnel mode for the current request and
>>then expect to be 1.1 again afterwards?
>
>Once a proxy agrees to tunnel, it does not take part of the HTTP
>communication and stays in tunnel mode until both transport connections
>have been closed, see 1.2:
>
>	tunnel
>
>	An intermediary program which is acting as a blind relay between
>	two connections. Once active, a tunnel is not considered a party
>	to the HTTP communication, though the tunnel may have been initiated
>	
>	by an HTTP request. The tunnel ceases to exist when both ends of the
>	relayed connections are closed.
>
>There is actually a bug here - the 101 (Switching Protocol) status code is
>passed though proxies (and-to-end) while the Upgrade header field it is
>responding to is hop-by-hop. This means that a client behind a proxy will
>get the 101 response even though it hasn't asked for an upgrade but the
>proxy did.

101 is not passed through proxies.  Section 10.1 excludes 1xx responses
that were requested by the proxy, as would be the case here.

>It should be mentioned that 101 (Switching Protocols) shouldn't be
>forwarded by proxies if not tunnelling. In 5.1, you mention that a proxy
>receiving a 101 should tunnel but this does not work if the proxy initiated
>the Upgrade header field by itself.

Actually, a tunnel is never a proxy, even if it was a proxy at some time
in the past.  The spec needs to be consistent in defining requirements
only in terms of the role of the application at the time of its
communication for that request/response.  Otherwise we would have to
place five exceptions after every requirement.

....Roy

Received on Monday, 2 August 1999 00:45:10 UTC