Re: [hybi] WebSocket feedback

[Vladimir Katardjiev <[e-mail]>]

On 4 mar 2010, at 16.44, Greg Wilkins wrote:
> 
> But the problem with this is it assumes success and that a 101 is the only
> possible response.

According to the current draft, page 22, step 31, there are two possible status codes accepted: 101 and 407. In the case of 407, the entire request (including the random challenge) will be resent. In the case of 101, the assumption holds. In any other case, the websocket handshake is considered to have failed.
> 
> I think that once we have gone through the process, it is very likely
> that we will see the need for return types other than 101.
> 
> For example, it will be hard to stop some servers sending a 401
> unauthorized if there are missing credentials. It might also be
> desirable to send 302 responses if a server has moved or wants
> to redirect to a non HTTP port or a secure https/wss port.

I'm not sure what a 401 could do to the client (the API doesn't allow credentials to be added, and I've never been a fan of the browser-generated "please log in" dialogs).

A 302 could be interesting. Apparently it's not in the spec right now, so maybe a new thread for that is in order?
> 
> So if websocket wants to have an exchange on the wire after the
> upgrade and before the framing starts, then sending non content
> bytes after the upgrade request has to be conditional
> receiving the 101... but then we have another round trip.
> 
> I really think we should stop trying to re-invent the HTTP upgrade
> mechanism.  If there are problems with normal HTTP upgrade, then
> raise them with HTTP bis.
> 
> If the bytes after the request header are sent as request content,
> what attack verctor is opened up?

I don't think it's an attack vector anymore. Originally, it was to prevent XHR/CORS from creating a WebSocket connection, but the requirements on Sec-* headers should avert that. Right now it has more to do with having a websocket connection fail early in case of an intermediary that doesn't understand websockets.

Vladimir