Jetty ( 9.2.3v20140905 )を使って遊んでいServerEndpointConfig
たときに、Jetty のコードに出くわして、それがどのように使用されているかを確認したときに、自分のエンドポイントを使用しようとした Web ソケット エンドポイントを接続しました。JsrCreator
Web ソケット オブジェクトの作成時に使用されていることに気付きました。
Object createWebSocket(ServletUpgradeRequest req, ServletUpgradeResponse resp){
...
// modify handshake
configurator.modifyHandshake(config,hsreq,hsresp);
...
}
modifyHandshake
次の状態のServerEndpointConfig
(javax.websocket-api 1.0)のjavadocを読みました。
整形式のハンドシェイク リクエストからハンドシェイク レスポンスを作成した後、コンテナによって呼び出されます。コンテナーは、この構成に一致する URIがあることを既に確認しており、 checkOrigin メソッドを使用してオリジンの有効性を判断し、この構成に基づいてネゴシエートされたサブプロトコルと拡張機能を入力しています。カスタム構成は、要求パラメーターを検査し、サーバーが定式化したハンドシェーク応答を変更するために、このメソッドをオーバーライドする場合があります。URIチェックも。 開発者がこのメソッドをオーバーライドしない場合、実装によるリクエストとレスポンスのそれ以上の変更は行われません。
Jetty の機能は次のとおりです。
Object createWebSocket(ServletUpgradeRequest req, ServletUpgradeResponse resp){
...
// modify handshake
configurator.modifyHandshake(config,hsreq,hsresp);
// check origin
if (!configurator.checkOrigin(req.getOrigin())){...}
...
resp.setAcceptedSubProtocol(subprotocol);
...
resp.setExtensions(configs);
}
ご覧のとおり、オリジンはコンフィギュレーターが呼び出された後にチェックされます。応答は、コンフィギュレーターが呼び出された後に変更されます。のメソッドacceptWebSocket
はWebSocketServerFactory
、WebSocketCreator を呼び出します。
Object websocketPojo = creator.createWebSocket(sockreq, sockresp);
その後、次のように呼び出します。
private boolean upgrade(HttpConnection http, ServletUpgradeRequest request, ServletUpgradeResponse response, EventDriver driver)
また、次を介して応答を変更しHandshakeRFC6455
ます。
// build response
response.setHeader("Upgrade","WebSocket");
response.addHeader("Connection","Upgrade");
response.addHeader("Sec-WebSocket-Accept",AcceptHash.hashKey(key));
とにかく、Jettyが変更するため、コンフィギュレーターだけで応答を変更する方法はありません。
Jetty は WebSocket の Java API である JSR 356 に準拠していないようです。