不支持/识别请求的websocket子协议时的HTTP响应代码

Question

将HTTP连接升级到websocket时,可以在可选的HTTP头"Sec-WebSocket-Protocol"中提供一个或多个子协议.

如果服务器接受任何子协议,它将使用HTTP响应代码101("HTTP/1.1 101交换协议")进行响应,并包含指示所选子协议的HTTP标头"Sec-WebSocket-Protocol".

但是服务器应该如何正确处理未知/不支持的子协议？

这应该在HTTP连接"内部"完成 - 使用一些HTTP响应代码吗？

或者是否应该将连接升级到websocket - 并通过发送带有一些预定义websocket状态代码的"关闭框架"立即关闭服务器？

RFC6455说什么？我无法得出结论.现有服务器实现如何处理它？

问候/每/

Answer 1

从 RFC 6455 的简要浏览来看，我相信 WebSocket 子协议是可选的并且是经过协商的。在第 4.2.2节中的“服务器要求”下：

   /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).  The empty string is not the
      same as the null value for these purposes and is not a legal
      value for this field.  The ABNF for the value of this header
      field is (token), where the definitions of constructs and
      rules are as given in [RFC2616].

如果服务器不同意与客户端使用子协议，则服务器不应发送具有非“null”值的子协议响应标头，此时客户端有责任继续或终止连接。