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

[Benjamin Black <[e-mail]>]

I actually removed a sentence saying approximately "I don't see how
this matters to anyone but Google", but thought it too snarky.  Next
time I'll know!

My suggestion?  Use existing HTTP auth, since that is easier for
everyone else.  Implement alternative schemes in Chrome and for your
apps (the client side will know to use the Google auth mechanism, and
its use will tell the server what is going on).  I see no reason the 2
need be in conflict.  If the non-HTTP mechanisms prove to be a major
win, and there is general demand for them, contribute them to the WG.
The additional experience in implementation and operations will make
your arguments in their favor irresistible.

It is in the best interests of this work to start with a minimal set
of features, making as much use as possible of existing infrastructure
(in this case, mostly HTTP).


b

2010/9/3 Ian Fette (イアンフェッティ) <[e-mail]>:
> 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" <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>