Re: Comments on HTTP TLS Upgrade draft

At 00:31 02/08/1999 -0700, Roy T. Fielding wrote:

>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 think the experience from the current use of User-Agent shows that people
in practice tends to overload simple tokens with as much information as
possible. Although it is slightly different from the Upgrade header field
tokens, the exchange of metadata about the communication should be light
weight and not necessarily cost an extra RTT. Solving this using first
class objects is much to be preferred - hence the push for HTTP extension
framework. 

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

Duh - I was looking at draft 07 where it wasn't mentioned. I am glad it is
now.

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

I agree - it was the point in the draft about transition from proxy to
tunnel that I was objecting against.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 2 August 1999 17:56:31 UTC