Re: [hybi] Extensibility mechanisms?

[Greg Wilkins <[e-mail]>]

Mike Belshe wrote:

> Should intermediaries know about these protocols?  Why?
> ...
> If we run all websockets through SSL, the protocol is stronger.  And
> poor users aren't left holding the bag wondering why they just got hacked.


Mike,

I'm not arguing against SSL or having that the
default/preferred transport.

But in many deployments, SSL will be terminated on a box
remote from the application and the connection will go through
intermediaries provided by many vendors for load balancing,
aggregation, connection aggregation etc. The specification
needs to support such intermediaries in 2020.

But to make it to 2020, we also need something that is
deployable in 2010.  So that means respecting the HTTP
protocol.

What Ian is proposing is that a websocket client and server
can just agree on some new field, that can be used to
upgrade to any protocol they like eg BEEP!

HTTP has an upgrade mechanism and it's called Upgrade.
Websocket should not be allowed to subvert that with
something like:

   GET /something HTTP/1.1
   Host: somewhere:80
   Upgrade: WebSocket
   Connection: Upgrade
   My-Upgrade: BEEP

        HTTP/1.1 101 Web Socket Protocol Handshake
        Upgrade WebSocket
        Connection: Upgrade
        My-Upgrade: BEEP

   <-- Beep frames -->

Any intermediary involved will have seen that
as an upgrade to WebSocket, not to BEEP.
I can't see how that can be interpreted as
a compliant HTTP upgrade.




Finally,  if I  really try to imagine protocols
in 2020, I can't see secure connections being
allowed end to end in all environments.   For
better or worse, Corporations (and even countries)
like to monitor and apply policy to what their
users are doing.  I can imagine that every
hop will be encrypted, but I think that end
to end will not be universal (unless there
some some huge break out of progressive
libertarian sentiment in fortune 500 and
world governments).


regards