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

[Benjamin Black <[e-mail]>]

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