[whatwg] Issues with Web Sockets API

(cc'ing hybi by request, since changes to the WebSocket spec are
discussed below)

On Thu, 22 Oct 2009, Alexey Proskuryakov wrote:
> 17.10.2009, ? 3:20, Ian Hickson ???????(?):
> > 
> > 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?
> 
> Formally limiting support for Basic auth would be workable, I guess. 
> Implementation of Digest authentication is already non-trivial enough 
> for me to wish that we don't implement it at first.
> 
> Or perhaps authentication should be limited to cookies in v1 indeed.

Ok, I've removed the authentication stuff from this version.


> > > > > > 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?
> 
> Hmm, I actually don't know for sure. Step 2 only covers the case when 
> the user agent is configured to use a proxy - but an organization may 
> have a transparent proxy intercepting requests. But I do not know if 
> such a proxy can practically request authentication by returning a 407 
> response (blurring the meaning of "transparent" a bit, but anyway).

I don't see how such a proxy could handle WebSocket anyway. The WebSocket 
protocol isn't really intended to be proxied.


> > 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?
> 
> If the answer to my above concern is yes, then it should work, as long 
> as the text doesn't require double TLS handshake or something like that.

I've added text in the spec that says to handle 407 basically like HTTP, 
closing the connection and jumping back to step 2.


> > 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.
> 
> Yes, I think that relying on HTTP specs to define authentication to Web 
> Sockets takes the "fake HTTP handshake" concept too far.

Ok. We'll revisit this in the next version, I guess.

I'm not sure there's really much point doing anything beyond cookie auth 
anyway.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 22 October 2009 21:20:42 UTC