公式サポートページの「Tomcat と Apache の連携方法」通りにhttpd.confを設定しても、チャット機能で以下のエラーが出て解決しなかったため、原因と対処法を共有します。同じ症状で検索されている方の参考になればと思います。環境GroupSession Ver5.7.3Windows / Apache 2.4.68(OpenSSL 3.6.3、Win32) / Tomcat 9.0.65ブラウザ: Google Chrome症状チャット画面を開くと赤字で「エラーが発生しました。リアルタイム通信を行うことができません。」と表示され、メッセージの送受信ができない。※このエラーはSharedWorker(sharedworker.js)内で発生するため、通常のブラウザ開発者ツールのConsoleには出ません。chrome://inspect/#workersから該当のSharedWorkerを選んで「inspect」すると、専用のDevToolsでエラーが確認できます。Tomcat側のログ(localhost.*.log)には以下が記録されていました。java.lang.UnsupportedOperationException: このプロトコルは HTTP アップグレードに対応していません。原因公式ドキュメントのサンプル設定は、同じ<Location /gsession/>内に通常リクエスト用: ProxyPass ajp://localhost:8009/gsession/WebSocket用: 条件付きRewriteRule .* ws://localhost:8080%{REQUEST_URI} [P]を併記する構成になっていますが、Apacheの処理順序上ProxyPassが先に確定してしまい、WebSocketアップグレード要求も含めて全リクエストがAJP側(8009番)に流れてしまいます。AJPはHTTP Upgradeに非対応のため、上記の例外が発生していました。対処法<Location>で個別に囲まず、ProxyPassをフラットに並べる形式に変更すると解決しました。ProxyPass /gsession/common/connection ws://localhost:8080/gsession/common/connectionProxyPass /gsession/ ajp://localhost:8009/gsession/<Location /gsession/>Require all granted</Location>これでProxyPass同士が最長一致(具体的なパス優先)で正しく振り分けられ、チャット用のWebSocket接続先(/gsession/common/connection)だけがTomcatのHTTPコネクタ(8080番)へ、それ以外は従来通りAJPへ転送されるようになります。curlで直接WebSocketハンドシェイクを試し101 Switching Protocolsが返ることを確認済み、既存機能の応答速度への影響もありません。※なお、上記を直しても自己署名証明書に**SAN(Subject Alternative Name)**が含まれていないとブラウザ側で別のエラー(ERR_CERT_AUTHORITY_INVALID等)になるので、自己署名証明書を使っている場合はSAN付きで発行し直す必要がある点もあわせてご注意ください。
vertical_align_top