On Mon, 31 Aug 2009, Alexey Proskuryakov wrote: > > > > 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?
What would you do in the same situation for HTTP URLs? > Also, what if the client has already performed digest authentication > with several nonce values? Same question. > 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. > > 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. > > -> 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. Yeah, that's quite possible. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'