[hybi] Client offers invalid WS protocols, what must the server do? 101???

[Iñaki Baz Castillo <[e-mail]>]

Hi, the draft (12) says:

       /subprotocol/
          Either a single value representing the subprotocol the server
          is ready to use or null.  The value chosen MUST be derived
          from the client's handshake, specifically by selecting one of
          the values from the "Sec-WebSocket-Protocol" field that the
          server is willing to use for this connection (if any).  If the
          client's handshake did not contain such a header field, or if
          the server does not agree to any of the client's requested
          subprotocols, the only acceptable value is null.  The absence
          of such a field is equivalent to the null value (meaning that
          if the server does not wish to agree to one of the suggested
          subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
          header field in its response).


So if the server just supports protocols "aaa" and "bbb" but the
client offers "ccc" and "ddd", the above text states that the server
must reply 101 without Sec-WebSocket-Protocol header.

So then, *what* are the client and the server supposed to speak now??
If the client has ***explicitly*** offered protocols "ccc" and "ddd"
and the server does not support them, the server should REJECT the WS
handshake, sure, rather than sending a 101. IMHO "501 Not Implemented"
could be a good HTTP response for this case.

The WebSocket handshake (HTTP GET + 101) is a negotiation between
client and server. If the negotiation fails, the WS GET request MUST
be rejected rather than accepted.

The current text seems to allow ugly JavaScript developers to set a
random protocol string (just for funny) in the Websocket JS API for
the function "connect(URL, protocols)". Please make it strict.


Regards.


-- 
Iñaki Baz Castillo
<[e-mail]>