すべてのプロダクト
Search
ドキュメントセンター

Edge Security Acceleration:レスポンスヘッダーの変更

最終更新日:Jun 24, 2025

HTTP 応答ヘッダーは、Edge Security Acceleration (ESA) プレゼンスポイント (POP) の HTTP 応答メッセージの一部であり、クライアントに渡す特定の応答パラメーターを伝送します。HTTP 応答ヘッダーを設定すると、ESA POP はリソースを返す際に応答ヘッダーを制御します。ESA では、必要に応じて HTTP 応答ヘッダーを追加、変更、および削除できます。

レスポンスヘッダー変更の仕組み

クライアントがリソースをリクエストすると、リクエストは最初に ESA に到達します。ESA POP のキャッシュにヒットしない場合、ESA はオリジンサーバーへのリクエストを開始してデータを取得します。オリジンサーバーがデータを返した後、ESA POP は、設定されたルールに基づいて元のレスポンスを変更します(特定のフィールドの追加、置換、削除など)。その後、ESA POP は、レスポンスヘッダーを含む完全なリソースをクライアントに返して、クロスオリジンリソースシェアリング( CORS )を実装し、キャッシュポリシーを最適化します。

image

シナリオ

  • ESA によって返されるコンテンツのタイプをクライアントに通知するESA: たとえば、Content-Type: text/htmlESA レスポンスヘッダーを追加して、ESA によって返されるコンテンツが HTML 形式であることをクライアントに通知し、関連するレンダリングを実行できます。

  • CORS を実装する: クライアントが ESA に追加された Web サイトのリソースをリクエストする場合、ESA から送信される応答メッセージで Access-Control-Allow-Origin ヘッダーを構成して、CORS を有効にできます。

  • カスタムレスポンス動作を指定する: カスタムヘッダーを追加または変更して、特定の機能を実装したり、レスポンスを追跡したりできます。 たとえば、必要に応じて、クライアントに返されるレスポンスコンテンツと形式を調整できます。

始める前に

複数のレスポンスヘッダー変更ルールを作成する場合、ルールはリストの上から下へ実行されます。 複数のルールが同じレスポンスヘッダーを変更する場合、最新のルールは以前に作成されたルールを上書きします。 ルールの実行結果が期待どおりにならない場合があることに注意してください。 例:

  • ルール 1:cache-control: max-age=3600 レスポンスヘッダーを追加します。

  • ルール 2:cache-control: no-cache レスポンスヘッダーを追加します。

ルール 1 とルール 2 が同時に存在する場合、ルール 2 はルール 1 よりも優先されます。つまり、返されるコンテンツはキャッシュされません。

レスポンスヘッダーの変更

ルールは、優先順位に従って有効になります。

  1. ESA コンソールで、[ウェブサイト] を選択し、管理するウェブサイトの名前をクリックします。

  2. 左側のナビゲーションウィンドウで、[ルール] > [変換ルール] を選択します。

  3. [レスポンスヘッダーの変更] タブをクリックします。[ルールを追加] をクリックし、[ルール名] を入力します。

  4. [リクエストが以下のルールと一致する場合...] エリアで、受信リクエストと一致する条件を指定します。ルールの構成方法の詳細については、「ルール」をご参照ください。

  5. [レスポンスヘッダーの変更] 領域で、[操作] ドロップダウンリストから値を選択し、[レスポンスヘッダー名][レスポンスヘッダー値] に入力します。

    次のリストは、操作と関連するヘッダー名と値について説明しています。

    追加

    • タイプ: 静的

      • 説明

        • クライアントに返されるレスポンスメッセージに特定のレスポンスヘッダーを追加します。

        • クライアントリクエストに指定した名前と同じ名前のヘッダーが含まれている場合、新しく追加されたヘッダーはクライアントリクエストの既存のヘッダーを上書きします。

      • 名前が x-code で、値が key1 のレスポンスヘッダーを追加します。 値の例:

        • [レスポンスヘッダー名]: x-code

        • [レスポンスヘッダー値]: key1

    • タイプ: 動的

      • 説明

        • レスポンスヘッダーを式に設定できます。 詳細については、「ルールを使用する」をご参照ください。

      • 名前が Client-Ip-Geo-Location で、値が ip.geoip.country のレスポンスヘッダーを追加します。 値の例:

        • [レスポンスヘッダー名]: Client-Ip-Geo-Location

        • [レスポンスヘッダー値]: ip.geoip.country

        Client-Ip-Geo-Location は、クライアント IP アドレスの地理的位置の国または地域を記録するために使用されるカスタムヘッダーです。

    変更

    • タイプ: 静的

      • 説明

        • レスポンスヘッダーの値を変更します。

        • クライアントリクエストに、指定した名前に一致するヘッダーが含まれていない場合、変更は無効です。

      • 名前が x-code のレスポンスヘッダーの値を key2 に変更します。 値の例:

        • [レスポンスヘッダー名]: x-code

        • [レスポンスヘッダー値]: key2

    • タイプ: 動的

      • 説明

        • レスポンスヘッダーを式に設定できます。 詳細については、「ルールを使用する」をご参照ください。

      • 名前が Client-Ip-Geo-Location のレスポンスヘッダーの値を ip.geoip.country に変更します。 値の例:

        • [レスポンスヘッダー名]: Client-Ip-Geo-Location

        • [レスポンスヘッダー値]: ip.geoip.country

        元のレスポンスに含まれる Client-Ip-Geo-Location ヘッダーの値は、クライアント IP アドレスの地理的位置の国または地域に変更されます。

    削除

    • 説明

      クライアントに返されるレスポンスメッセージから、[レスポンスヘッダー値] 列の値と一致するすべてのレスポンスヘッダーを削除します。このようなレスポンスヘッダーがいくつ存在するかに関係なく削除されます。

    • 名前が x-code のレスポンスヘッダーを削除するには、[レスポンスヘッダー名] 列に x-code と入力します。

    • 説明
      • ali- または Ali- で始まるレスポンスヘッダー名を指定することはできません。

      • レスポンスヘッダーに 1 つ以上の値を指定できます。 値はカンマ(,)で区切ります。

      • 削除操作の構成効果は、静的モードと動的モードで同じです。

      • 元のレスポンスに存在するヘッダーの名前のみ変更できます。

  6. [OK] をクリックします。

レスポンスヘッダー

次のリストは、レスポンスヘッダーについて説明しています。

  • カスタム

    • 必要に応じて、カスタムレスポンスヘッダーを作成できます。 次のルールに基づいて、レスポンスヘッダーの名前を指定する必要があります。

      • 名前には、文字、ハイフン(-)、および数字を含めることができます。

      • 名前の長さは 1 ~ 100 文字である必要があります。

    • 例: Test-Header

  • Cache-Control

    • リクエストとレスポンスが従うキャッシュルール。

    • 例: no-cache

  • Content-Disposition

    • 取得したコンテンツをクライアントのファイルとして保存するときに使用されるデフォルトのファイル名。

    • 例: examplefile.txt

  • Content-Type

    • クライアントに返されるリソースのメディアタイプ。

    • 例: text/plain

  • Pragma

    • Pragma は、サーバーレスポンスでキャッシュ制御ディレクティブを伝送するために使用される HTTP/1.0 汎用タイプのヘッダーです。

    • 例: no-cache

  • Access-Control-Allow-Origin

    • どのソースがリソースにアクセスできるかを指定します。 これは CORS メカニズムの一部であり、サーバーはリソースに指定されたソースドメイン名からアクセスできるかどうかを宣言できます。 このレスポンスヘッダーの値は、次のタイプをサポートしています。

      • ワイルドカード文字(*: ワイルドカード文字を使用すると、任意のソースからのリソースへのアクセスを許可できます。このアプローチは非常に寛容であり、認証または権限付与なしで公開アクセスできるリソースに適しています。ただし、クロスサイトリクエストフォージェリ(CSRF)攻撃などのセキュリティリスクが発生する可能性があるため、本番環境ではワイルドカード文字を慎重に使用する必要があります。

      • 指定されたソース: ソースドメイン名を指定して、この特定のソースのみがリソースにアクセスできるようにすることができます。 例: http://example.com または https://api.example.com。 リクエストは指定されたソースからのものである必要があります。 そうでない場合、リクエストは拒否されます。

    • 例:

      • *

      • http://www.alibabacloud.com

  • Access-Control-Allow-Methods

    • クロスオリジンリクエストで使用できるリクエストメソッド。 1 つ以上のリクエストメソッドを指定できます。 リクエストメソッドはカンマ(,)で区切ります。

    • 例: POST,GET

  • Access-Control-Allow-Headers

    • クロスオリジンリクエストで使用できるヘッダーフィールド。

    • 例: X-Custom-Header

  • Access-Control-Expose-Headers

    • レスポンスの一部として公開できるヘッダー。

    • 例: Content-Length

  • Access-Control-Allow-Credentials

    • ブラウザがフロントエンドページへのレスポンスを公開できるかどうかを指定します。

      • true: ブラウザはフロントエンドページへのレスポンスを公開できます。

      • その他の値: ブラウザはフロントエンドページへのレスポンスを公開できません。

    • 例: true

  • Access-Control-Max-Age

    • プリフライトリクエストの結果をキャッシュできる期間。 単位: 秒。

    • 例: 600

説明
  • ヘッダーをアスタリスク(*)に設定できます。これはすべてのオリジンと一致します。

  • 1 つ以上の IP アドレス、ドメイン名、または IP アドレスとドメイン名の組み合わせを構成できます。 複数の値はカンマ(,)で区切ります。

  • ヘッダーのワイルドカード文字としてアスタリスク(*)を使用しない場合、値は http:// または https:// で始まる必要があります。

  • ポート番号がサポートされています。

  • ワイルドカードドメイン名がサポートされています。