Strict Transport Security（HSTS）HTTP Response Header Security関連の質問
HSTSヘッダーはサーバー固有であると常に思っていました。このヘッダーが特定のURIエンドポイント間で呼び出されない理由は何ですか。つまり、HSTSヘッダーはルートダイレクト/および/ contact/doctorsに応答しますが、/ contact/nursesには応答しません。 。
誰かがこれを私に説明してくれませんか？
すべてのHTTP（S）ヘッダーは、サーバーがネットワーク経由で送信する単なるデータです。それは文字通りプレーンテキストであり、通常はASCII/UTF-8です。サーバーは、受け取った要求に応じて、構成されているヘッダー（または本文）を送信できます。すべての応答で特定のヘッダーを送信するようにサーバーを構成することはcommonですが、これが唯一のオプションではなく、必ずしも最善の方法でもありません。
時々、効率の理由で異なる応答が送信されます。たとえば、古すぎて理解できないブラウザーにヘッダーを送信しなかったり、異なるHTTP/CSS/JSを異なるブラウザーに提供したりします（ヘッダーは、本文と同様に、単なるデータであり、任意に制御される）。パスが異なると、コンテンツやセキュリティポリシーが異なる場合があります。ただし、サーバーは、他のソフトウェアが実行できるすべてのことを実行するように構成できます。特にばかげた例では、サーバーは100回のリクエストごとに適切なHTTP応答の送信をまったくスキップし、「私は小さなティーポットです」というテキストを返すだけです。これは悪いユーザーエクスペリエンスですが、サーバーを構成するのはthat難しいことではありません（ほとんどのWebフレームワークは、少なくとも最初の行と応答コードを自動的に送信しますが、いくつかの努力でそれを回避することができます）。
また、サーバーへのドメイン名の1：1マッピングがないことに注意してください。単一のドメイン名がバックエンドの多くの異なるサーバーによって提供され、ソフトウェアがドメインのパブリックアドレスに配置され、TLSを終了し、リクエストを多数のバックエンドサーバーの1つにルーティングする場合があります。それらのバックエンドサーバーの一部は、すべての要求でHSTSヘッダーを送信する場合もあれば、何もない場合や、他の条件で送信する場合もあります（おそらく「毎週木曜日」ではありませんが、そうかもしれません！）。
有効であると見なされるには、すべてのURIに対してHSTSヘッダーが返される必要があります。これは、ヘッダーがホスト全体（オプションでサブドメインを含む）である一方で、ユーザーがリソースにアクセスするのを最初に停止するものがないためですこれはHSTSヘッダー（例では/ contact/nurses）を返さないため、そのURIと安全に通信することができません。
RFCを実装するクライアントが、1（例では/ contact/doctors）を返すURIにアクセスしてHSTSヘッダーを正しく認識するとすぐに、ドメイン全体（およびオプションでサブドメインの場合はサブドメイン）にヘッダーを適用します。ヘッダーはそれを要求します）。
たとえば、過去にこの誤った構成が意図的に使用されたのを見たことがあります。たとえば、（ここでも例を使用すると）その目的は、/ contact/nurses URIが特定のモバイルアプリまたはクライアントのサブセットによってアクセスされることです。管理者/開発者は、HTTPSではなくHTTPでこれを行いたいと考えています。モバイルアプリなどの開発者が制御するクライアントの場合、開発者はクライアントがHSTSヘッダーを返すリソースにアクセスしないようにすることができるため、これは技術的に機能します。