Re: [hybi] WebSocket feedback

[Greg Wilkins <[e-mail]>]

Vladimir Katardjiev wrote:


>> The server needs to consider the bytes of content before formulating the accepting the upgrade request and sending the 101 response, so it can't be considered as data in the
>> stream after the 101.
> 
> Unless I'm reading it completely wrong, the contents of the 101 handshake (since it has no content-length) can and are constructed purely from the headers. The challenge
> response contains data from both headers and the 8-byte challenge that comes later, but it's fine to do it. The steps of the algorithm could be reordered with no change of the
> output so what we call it is a matter of interpretation. Po-tay-to, poh-ta-to.

But the problem with this is it assumes success and that a 101 is the only
possible response.

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.

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?

Note that it is OK for the response bytes to be sent as the
first bytes of the stream (and not part of the 101).

regards