Re: [hybi] workability (or otherwise) of HTTP upgrade

[Zhong Yu <[e-mail]>]

On Wed, Dec 8, 2010 at 10:10 PM, Jack Moffitt <[e-mail]> wrote:
> One path is to combine the separate port idea along with the encryption based approach.

Great argument! I think you nailed it.

Guys, please hear this out.

Because we can always achieve the highest success rate with WSS on
port 433, we can, and we shall,  completely drop the concern of
success rate from WS protocol design.

Success rate is a problem only in the early phase of WS adoption, and
even then majority of applications won't be affected, since their
target users are home users with simple networks.

Of course we must care about "serious" applications that strive to
reach every internet user, especially users behind corporate
firewalls. The good news is, there is *the* perfect solution --
WSS:433. These companies can certainly afford this solution. Actually
such applications probably shall use TLS anyway just for data privacy.

According to
http://www.ietf.org/mail-archive/web/hybi/current/msg05003.html
the success rate of TLS on 433 is about 95%. There is *nothing* WS can
do to beat that. Whichever trick we put in WS to improve success rate
will be in vain, because people who really care about success rate
must do WSS:433 anyway.

If we drop the concern of success rate from WS design, we gain a lot
of freedom. No more Upgrade or CONNECT, it's moot. Simply design a
brand new syntax that's completely independent of HTTP.

In the early phase of WS adoption, we will advise developers that
plain WS could have problems with some firewalls for some users. They
should measure *their* success rate against *their* user base. If the
success rate is unacceptable, they can always fall back on WSS:433.

WS clients should relax the rules of certificate validation. Don't
panic on self-signed certificates like current browsers do which
doesn't make any sense. If WSS with self-signed certificates are not
treated more badly than plain WS,  frugal application developers don't
need to spend any money to use WSS for the purpose of improving
success rate. WS server can even automate self-signed certificate so
that developers don't need to spend much time either.

If WS and HTTP syntax are completely different, it is still not a
problem for them to share port(if so desired), as long as WS traffic
has some magic text at the start. Web servers must be modified if they
want to handle WS, that is to be expected. WS and HTTP are so
different in modes of operation, it's unrealistic to require that WS
can be implemented as a module to an existing HTTP server, without
touching the HTTP server itself. If we drop the HTTP head from WS, it
will only reduce overall work for server implementors.

There are other server side components that also have to be upgraded
to handle WS. We should not be too sympathetic to them. We got enough
problems already, server side inconvenience should have the lowest
priority. Separation of WS and HTTP will be more beneficial to the
server side people. Mixing WS and HTTP will become a perpetual source
of trouble.

- Zhong Yu

On Wed, Dec 8, 2010 at 10:10 PM, Jack Moffitt <[e-mail]> wrote:
> One path is to combine the separate port idea along with the
> encryption based approach. On the WebSocket port, you could avoid all
> the intermediary issues, but perhaps be limited by firewalls.
> However, you would not need any obfuscation and could easily use
> sendfile().  On the TLS port you use NPN to get a WebSocket that is
> not going to cause security problems with intermediaries.
>
> For the short term, we get WebSocket on the port with the highest
> success rate, and in the long term, we have firewalls accepting the
> new port as killer applications make people care.
>
> If we're going to lose the sendfile(), why not go the rest of the way?
> Or is there something I'm missing in the port 80 but just XORed case?
>
> jack.
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>