[whatwg] Issues with Web Sockets API

[Alexey Proskuryakov]

13.10.2009, в 4:11, Ian Hickson написал(а):

>> Is this meant to mimic some behavior that existing clients have for  
>> HTTP
>> already?
>
> Yes, as it says, the idea is for UAs to send the same headers they  
> would
> send if the protocol had been HTTP.

For HTTP, this depends on authentication scheme in use. For Basic and  
Digest authentication in particular, clients are allowed to make  
certain assumptions about protection spaces: "A client MAY  
preemptively send the corresponding Authorization header with requests  
for resources in that space without receipt of another challenge from  
the server."

I don't think the Web Sockets protocol is sufficiently similar to HTTP  
to defer to RFC 2617 or other HTTP specs here. Also, implementing  
"just support the same authentication mechanisms you do for HTTP" is a  
tall order, since HTTP back-ends don't (always?) expose the necessary  
APIs for encryption.

>>> If /code/, interpreted as ASCII, is "401", then let /mode/ be
>>> _authenticate_. Otherwise, fail the Web Socket connection and  
>>> abort these
>>> steps.
>> 407 (proxy authenticate) also likely needs to be supported.
>
> Proxies wouldn't work with WebSockets in general.

Could you please elaborate? I thought there was a setup that could  
work with most deployed HTTPS proxies - one could run WebSockets  
server on port 443.

A feature that doesn't work behind proxies suddenly makes a lot less  
sense - one could use it to control a toy railroad over intranet, but  
do other use cases survive?

>> Some authentication schemes (e.g. NTLM) work on connection basis,  
>> so I
>> don't think that closing the connection right after receiving a
>> challenge can work with them.
>
> Yeah, that's quite possible.


Is this something you plan to correct in the spec?

If practical uses of Web Sockets are all going to be over SSL (for  
proxy compatibility reasons), then even Basic auth seems ok for many  
cases, but NTLM still has important benefits over it. The primary  
benefit I'm aware of is that passwords don't need to be stored on the  
server.

- WBR, Alexey Proskuryakov