- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 17 Oct 2009 10:20:55 +0000 (UTC)
On Wed, 14 Oct 2009, Alexey Proskuryakov wrote: > 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. I'm not really sure what else to say to be honest. Should I just leave it at cookies and nothing else? Really I just want to support Basic (and I guess Digest) authentication (primarily for over-TLS connections), so that sites that use Basic auth, like, say, porn sites, or the W3C, can also use it for their Web Socket connections. I could just limit it that way; would that work? > > > > 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. Oh, I see what you're saying. Proxy authentication of this nature is covered by step 2 of the handshake algorithm, as part of "connect to that proxy and ask it to open a TCP/IP connection to the host given by /host/ and the port given by /port/". There's even an example showing auth headers being sent to the proxy. By the time we get down to parsing the response, we're long past the point where we might be authenticating to a proxy. Is that a problem? I could add support for 407 here and just say that you jump back to step 2 and include the authentication this time, would that work? > > > 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? Is there much to correct? I don't understand what would need to change here. Does NTLM not work with HTTP without pipelining? Or do you mean that you would rather have authentication be a first-class primitive operation in Web Socket, instead of relying on the HTTP features? We could do that: instead of faking an HTTP communication, we could have a header in the handshake that means "after this, the client must send one more handshake consisting of an authentication token", and if the UA fails to send the right extra bit, then fail. I think if we did this, we'd want to punt until version 2, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 17 October 2009 03:20:55 UTC