[whatwg] Issues with Web Sockets API

04.08.2009, ? 16:47, Ian Hickson ???????(?):

> I've added support for redirects. While I was at it I also added  
> support
> for authentication.


Reading the authentication part of the latest draft, I had several  
comments:

> 9. If the client has any authentication information <...> that would  
> be relevant to a resource accessed over HTTP, if /secure/ is false,  
> or HTTPS, if it is true, on host /host/, port /port/, with /resource  
> name/ as the path (and possibly query parameters), then HTTP headers  
> that would be appropriate for that information should be sent at  
> this point. [RFC2616] [RFC2109] [RFC2965]

I'm not sure how this part translates into actual behavior. What if  
there are several sets of credentials already known to the client, for  
example? Also, what if the client has already performed digest  
authentication with several nonce values?

Is this meant to mimic some behavior that existing clients have for  
HTTP already?
> 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.
> -> If the entry's name is "www-authenticate" Obtain credentials in a  
> manner consistent with the requirements for handling the |WWW- 
> Authenticate| header in HTTP, and then close the connection (if the  
> server has not already done so)

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.

- WBR, Alexey Proskuryakov

Received on Monday, 31 August 2009 12:31:56 UTC