ハードウェアロードバランサの背後にあるJavaサーブレットがあります。ロードバランサはhttps要求のみを許可します。問題は、サーブレットで要求を受け取ったときにのみ見ることができ、サーブレットに到達するまでに復号化されたように見えます。これは、サーブレットがセキュリティを心配する必要がないためです。ただし、サーブレットでリダイレクトを送信する場合は、http要求であるためロードバランサによってリクエストがブロックされます。リダイレクトがHTTPで動作しない
いくつかのソリューションについては、this oneと似ています。基本的には、リクエストURLを最初に捕捉するサーブレットフィルタを追加することをお勧めします。
私は試しましたが、うまくいかなかった。サーブレットが実際のリクエスト（http/https）を知る方法がない限り、サーブレットフィルタはどのような助けになりますか？私はそれがかなり一般的だと思うので、私はこの問題に対する標準的な解決策があるのだろうかと思います。
HTTPSはSSL上のHTTPプロトコルに過ぎません。証明書を使用してクライアント&サーバー間で転送されるデータパケットのみを暗号化します。
サーブレットは、使用されているメカニズムが何であれ迷惑にならないようにする必要があります。転送プロトコルは、クライアント&コンテナの間の契約です。サーブレットは、ネットワークレベルで通信がどのように行われるかを透過的に保ちます。
リダイレクトの警告はセキュリティ対策のために発生している可能性があります。一般的に、最新のブラウザではHTTPからHTTPSに移行できますが、他の方法では移行できません。
たとえば、ホームページがHTTPSに読み込まれていても、ブラウザが非同期呼び出し（すべてのajax呼び出し）をHTTP経由でブロックする場合。これは、サイトのすべてのページでHTTPSを使用するように強制するために行われます。
1）を使用すると、クライアントのブラウザでこの警告を得ている：
チェックしたいかもしれませんここ2つのシナリオがあるかもしれません。私はすでに上記で説明したように、これがあなたの問題の原因かもしれません。
2）ブラウザと同様に、ロードバランサはこのようなセキュリティ強制を行っている可能性があります。
ヒント：一般的に私たちのサーブレットやバックエンドコードでリダイレクトを使用するときはいつでも。 URLを使用している場合は、明示的にプロトコルを指定しないでください。リダイレクションコードや他の場所に置くことができます。でもあなたは
いけない書き込みを生成しているアンカータグで：
<a href="http://mywebsite.com/page1"> page1 </a>
その代わり、URLが同じドメイン内にある追加した場合、また、ドメイン相対URLを使用（クライアントブラウザがプロトコルを処理させる絶対URLを使用してください。あなたのサイトの外部にある場合のみ）。
<a href="mywebsite.com/page1"> page1 </a>
HTTPSを使用しているかどうかにかかわらず、同じサーブレット/バックエンドコードが機能する場合は、この方法です。
もう1つ：HTTPSまたはSSLを介したHTTPは、クライアント&ウェブサーバーレイヤーの間です。あなたのコンテナ/アプリケーションサーバは、それらの間に何が起こっているのかを知ることはできません。また、Webサーバ& Appserverとの間でSSLを使用し、エンドツーエンドの暗号化を行うことをお勧めします。
実際に、ロードバランサへのリクエストがhttpかhttpsかを知ることができます。ロードバランサは、元の要求について通知する特定のヘッダーを送信します。
例の場合、ロードバランサへのリクエストがHTTPSの場合は、X-SSL-Secure：trueヘッダーを送信します。
ここをクリックしてください。まさに私が理解し、私がやったのです
How can I know if the request to the servlet was executed using HTTP or HTTPS?
残念ながら、ロードバランサは私に 'X-SSL-Secure'ヘッダを渡しませんでした。 –
@あなたが受け取ることができるすべてのヘッダーをここに貼り付けることができます。彼らはいくつかの他のヘッダーを送信している可能性があります。 –
すべてのヘッダーをチェックしました。これらのヘッダーはすべて標準のもので、セキュリティとは関係ありません。ロードバランサが特定のヘッダーをhttpsに設定するためのプロトコルですか？ –
。私は 'response.sendRedirect（"/context/path/"）'です。 'http：// hostname/context/path /'にリダイレクトされます。問題は、ハードウェアロードバランサがHTTP要求を許可しないことです。だから、ブラウザがそのような要求をした後、それはちょうどそこにハングアップし、最終的にタイムアウトになります。ロードバランサは私が触れることができるものではありません。 –
こんにちは@JFreebird、このリダイレクトはどこで起こっていますか？あなたはすでにブラウザにhttp：//付きのURLを取得していますか？はいの場合、URLの書き換えが起こっている場所があります。一般に、多くのシステム（特にコンテンツ管理システム）は、壊れたURLを公開することを望まず、URLの書き換えメカニズムと呼ばれるものを持っています（したがって相対URLを絶対URLに変換する） 。これを行うWebサービスレイヤまたは負荷分散レイヤに何かがあるかどうかを確認します。 –
私はサーブレットでリダイレクトを送信し、ブラウザは応答を取得してリダイレクトURLを訪問します。私のブラウザは、httpsではなく、https：// hostname/path redirect urlを取得します。私はサーブレットがリダイレクトを送信しているときだけhttpについて知っているからだと思います。サーブレットから送信されたURL自体は完全ですが、httpです。だから私は壊れたURLがあるとは思わない。 –