これは、最初のリクエストを安全でない方法で発行しても問題ないことをユーザーに示しています。これが受け入れられるとは思えません。HTTP バージョンがヒットした場合に 404/500 ステータス コードを発行する属性を調べる前に、そのような属性は既に存在しますか?
http://
の代わりに を使用してこれらの URL に対してアプリケーションをまったく動作させたくない場合はhttps://
、何も提供しないでください (404 または接続なし)。
SSL/TLS が使用されていること (および有効な証明書で正しく使用されていること) を確認するのは、最終的にはユーザーの責任であることに注意してください。それらのアドレスへのリンクがhttps://
実際に使用されていること、およびユーザーがhttps://
少なくとも開始ページで使用されることを期待していることを確認してください。ブラウザーが HSTS をサポートしている場合は、HSTS の使用を検討できます (または、キャッシュされるエントリ ポイントへの永続的なリダイレクトの可能性があります)。
別のコメントから:
URLに関する情報が第三者に漏洩することを望んでいません
クライアントからこの URL を使用してリクエストが行われるhttp://
と、サーバー上で何をしてもほとんど意味がありません。手遅れです: 盗聴者が要求を見た可能性があります。(自分のページが外部の Web サイトにリンクしていない場合、リファラーにもそのアドレスは表示されません。) サーバーがプレーンな HTTP ポートをリッスンしていなくても、アクティブな MITM 攻撃者 (または、より簡単に言うと、プロキシ) は、サーバーに到達することなく、そのリクエストをリッスンして URL を取得する可能性があります。
繰り返しますが、ユーザーhttps://
が使用されることを期待していることを確認し、安全なページにアクセスしたら、サイトの他のセクションへのリンク/フォーム アクションがすべて を使用していることを確認してくださいhttps://
。