[whatwg] Issues with Web Sockets API
ian at hixie.ch
Sat Oct 17 03:20:55 PDT 2009
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
> > > > 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg