[whatwg] Issues with Web Sockets API

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'