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

[Scott Ferguson <[e-mail]>]

Benjamin Black 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?
>   

It's for non-browser applications, which have different latency and 
security requirements than browser-based applications. The 
authenticating "user" is a remote program. Thinking of cookies as 
authentication credentials is meaningless in this context.

Consider a messaging application which primarily sends single messages, 
but can either batch in short bursts or has a related event notification 
system for reading messages. Or think of the requirements of something 
like memcache or a query-based service like a database. A majority of 
the calls might be short request/response, and those might be the 
critical ones from a performance perspective. You might only have the 
WebSocket open for a short burst (1 sec) since connections are not 
always poolable for a long time in non-browser applications.  So you 
can't always just amortize extra handshake cost away.

If the WebSockets handshake overhead is sufficiently low, it can be used 
for the entire application. If it was identical to HTTP performance, it 
would always be a win. But if it's too high for the RPC, it may not be 
usable, and if the WebSockets performance is significantly worse than 
HTTP/RPC, it won't be a viable upgrade.

Suggesting a mix of HTTP and WebSockets a single application isn't 
really viable. You want the performance to be reasonable across a wide 
range of connection times.  It's not as simple as saying HTTP should be 
used for request/response and WebSockets used for long lived connections 
because both requirements may exist in the same application, or the 
burst rate may blur the distinction between the two..

If we follow your suggestion, non-browser applications would likely just 
use BASIC auth to avoid the handshake penalty. It wouldn't be a crisis 
since that's what many HTTP/webservice applications do today.  But it 
seems a shame to discourage the stronger challenge/response 
authentication and settle for sending passwords in the clear when we can 
enable challenge/response with zero extra overhead.

-- Scott
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>