Re: [hybi] WebSocket handshake (HTTP and SSO)

As a general point, we (Google) are very concerned with initial latency. The
addition of 50ms before an app is usable is nontrivial. I say that not to
argue for or against the current handshake, but rather to push back against
the notion that 50ms at startup doesn't matter. Time at startup is among the
most important, we can often hide delays at other points.

On Sep 3, 2010 10:08 PM, "Benjamin Black" <b@b3k.us> wrote:
> The focus of the argument in favor of re-implementing authn in
> Websockets mechanisms that already exist in HTTP is that the authn
> process sometimes requires an extra round trip. One. Round. Trip.
> Sometimes. The phrase you seek is "premature optimization".
>
> Instead of talking about it in the abstract of a single, extra round
> trip, I ask when this is relevant. In cases where connections are
> short-lived, intended for a single request/response, and credentials
> can't be retained, this concern seems quite important. Since the
> entire process is one round trip, adding another could add
> considerable latency.
>
> Are Websockets intended for short-lived, request/reply applications?
> If so, they are pointless as HTTP can handle these applications all on
> its own.
>
> Are they intended for applications in which:
> 1) a user is not already authenticated
> OR
> 2) the credentials can't be passed to the Websocket system to use in
> authentication?
>
> Or, instead, are Websockets intended for long-running connections with
> numerous round trips, often from applications that can collect
> credentials and send them directly in the HTTP request that begins the
> Websocket negotiation? And, if this is so, why are we obsessing over
> a single round trip adding all of 50ms to initial connection setup
> instead of recognizing the existing mechanisms are perfectly workable
> _as is_? If, in the fullness of time and experience, we discover the
> extra round trip is a serious impediment, we are free to design and
> implement new mechanisms.
>
> File under: another confusing example of hybi efforts eschewing HTTP
> mechanisms and HTTP compliance. If someone could elucidate that, I
> would be grateful.
>
>
> b
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi