Re: [hybi] Different server semantics of CONNECT

[Greg Wilkins <[e-mail]>]

On 7 December 2010 01:47, John Tamplin <[e-mail]> wrote:
> It seems that those so fundamentally opposed to using CONNECT are
> setting up a no-win situation.  If we can't use GET+Upgrade because
> real-world implementations never bothered to implement it because it
> wasn't actually used, and we can't use CONNECT because it is deemed to
> be in violation of the HTTP spec, then where does that leave us?  We
> can use a dedicated port, in which case WebSockets will not be usable
> in the near future for anyone behind a configured proxy (ie, most
> corporate environments and some home ones), ....


John,

I do mostly agree with you that definition of acceptable use of
CONNECT and the definition of "proxy" is being a little strictly
applied.

However, I don't agree being pushed to use a dedicated port will make
websocket less usable.    Consider the following experiment from the
Chrome team:

  http://www.ietf.org/mail-archive/web/tls/current/msg05593.html

whose results (from a small self selected sample) were:

  "The experiment tries to perform a trival WebSockets transaction over
   HTTP, over HTTP on a random, high numbered port (61985) and over
   HTTPS. This experiment is run via Chrome for users who have opted in.
   These are normal requests in the Chrome network stack and so will use
   any configured proxies.

   Excluding users that couldn't even do basic a HTTP transaction over
   the transport layer (6.37%, 10.15% and 7.91%, respectively), the
   success rates are:
       HTTP (port 80)      67%
       HTTP (port 61985)   86%
       HTTPS (port 443)    95%

   This results in overall sucess rates of 63%, 77% and 87%, respectively."

Thus a dedicated high port is going to have a success rate of 70-80%
I don't think that either CONNECT or GET+Upgrade handshakes are
claiming any significantly higher success rates.

Let's say we got permission to go crazy with the cheeze whiz and
change HTTP in any way that we liked, we are still looking at > 10%
that cannot establish a websocket connection over port 80.   Even port
443 is far from perfect.

All our proposed solutions suffer from connectivity issues - and I
don't think that it is the fault of strict application of the HTTP
specification.

We are beating ourselves up here saying: "your solutions is not
perfect" - "no your solution is not perfect" etc.   If we grind this
out to some kind of rough consensus on either connect or upgrade, we
are still going to have something that is not provably secure and will
fail in >10-20% of cases.

A dedicated port is going to give us
  + the same order of magnitude of success.
  + a much clearer security story.
  + a simpler argument to intermediary venders to support WS
  + the option of using a CONNECT handshake on port 80 to connect to it.

cheers