5

HTTP接続をWebSocketにアップグレードする場合、オプションのHTTPヘッダー「Sec-WebSocket-Protocol」に1つ以上のサブプロトコルを指定できます。

サーバーがサブプロトコルのいずれかを受け入れる場合、サーバーはHTTP応答コード101（ "HTTP / 1.1 101スイッチングプロトコル"）で応答し、選択されたサブプロトコルを示すHTTPヘッダー'Sec-WebSocket-Protocol'を含みます。

しかし、サーバーは不明な/サポートされていないサブプロトコルをどのように正しく処理する必要がありますか？

これは、HTTP接続内で「HTTP応答コードを使用して」実行する必要がありますか？

または、接続をWebSocketにアップグレードし、事前定義されたWebSocketステータスコードの一部を含む「CloseFrame」を送信してサーバーによってすぐに閉じる必要がありますか？

RFC6455は何と言っていますか？結論を出すことはできません。既存のサーバー実装はそれをどのように処理しますか？

よろしく/あたり/

4

2 に答える 2

4

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' 以外の値のサブプロトコル応答ヘッダーを送信してはならず、その時点で接続を続行または終了するのはクライアントの責任です。

于 2012-11-24T20:58:10.390 に答える
0

WebSocket の要点は、WebSocket を使用してクライアントからサーバーへの特定のプロトコルを実行することです。ただし、クライアントとサーバーはプロトコルを認識している必要があります。これにより、両端で、受信した WS メッセージをどう処理するかを知ることができます。WS メッセージの処理は、TCP レベルで行う場合と同じです。プロトコル フィールドを使用する必要はありません。互換性を強制したい場合にのみ関連します。

Kaazing サーバーには、基本的な websocket レイヤーの上にある特定のプロトコル ライブラリを提供します。Github にもさまざまなプロトコル ライブラリがあります。ハンドシェイクを除いて、他のすべては TCP で処理する方法です。Websocket メッセージを処理し、プロトコルのデコードを試みます。ライブラリが実際に一致するプロトコル ライブラリであることを確認するには、ハンドシェイクのプロトコル フィールドを使用する必要があります。したがって、たとえば、サーバーが STOMP を話し、クライアントに接続しようとして STOMP を話したい場合、STOMP ライブラリはプロトコル フィールドをチェックして一致することを確認する必要があります。エンドポイントは、たとえば AMQP 0.9 と AMQP 1.0 を話すことができ、両方が利用可能な場合は AMQP 1.0 を選択するなど、優先順に示すことができます。エンドポイントの 1 つが「

于 2012-11-27T18:41:20.130 に答える