- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Wed, 14 Oct 2009 13:27:11 -0700
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
Received on Wednesday, 14 October 2009 13:27:11 UTC