Media CDN では、カスタム リクエスト ヘッダーとカスタム レスポンス ヘッダーを指定できます。
カスタム ヘッダーを使用すると、次のことができます。
- 国、リージョン、都市など、クライアントに関する地理データを返し、ローカライズされたコンテンツの表示に使用できます。
- レスポンスがキャッシュから提供されているかどうか(全体または一部)と、レスポンスを送信するキャッシュのロケーションを決定します。
- リクエスト ヘッダーとレスポンス ヘッダーの両方を削除、置換、または追加します。
カスタム ヘッダーを設定する
ヘッダーは各ルートで設定されるため、マニフェストや動画セグメントなどのさまざまなコンテンツのヘッダーを追加、削除できます。
CDN 処理パスの早い段階で、キャッシュ保存の決定前に、ルートごとのカスタム リクエスト ヘッダーを設定します。たとえば、cache-control ヘッダーをルートごとのカスタム ヘッダーとして設定すると、CDN のキャッシュ保存動作に影響します。
デフォルトでは、追加されたヘッダー値はカンマ区切りで、同じフィールド名を持つレスポンス ヘッダーまたはリクエスト ヘッダーに追加されます。
既存の値を上書きするには、replace を true に設定します。
gcloud と YAML
EdgeCacheService リソースの YAML 構成を一覧表示するには、次のコマンドを使用します。
gcloud edge-cache services describe prod-media-service
.routing.pathMatchers[].routeRules[].headerAction セクションには、追加および削除されるヘッダーが表示されます。
routeRules:
- priority: 1
   description: "video routes"
   matchRules:
      - prefixMatch: "/video/"
   headerAction:
      responseHeadersToAdd:
      # Return the country (or region) associated with the client's IP address.
      - headerName: "client-geo"
         headerValue: "{client_region}"
         replace: true
      requestHeadersToAdd:
      # Inform the upstream origin server the request is from Media CDN
      - headerName: "x-downstream-cdn"
         headerValue: "Media CDN"
      responseHeadersToRemove:
      - headerName: "X-User-ID"
      - headerName: "X-Other-Internal-Header"
Terraform
次の Terraform スニペットは、カスタム ヘッダーを含むルートルールを示しています。
この例では、次の操作を行います。
- {client_region}変数を使用してレスポンスにカスタム- client-geoヘッダーを追加します。これは、クライアントの IP アドレスに関連付けられた国(またはリージョン)を返します。
- 静的文字列を使用して、リクエストにカスタム x-downstream-cdnヘッダーを追加します。
- 2 つの内部ヘッダーを削除します。
送信元固有のカスタム ヘッダーを構成するには、送信元固有のホストの書き換えまたはヘッダーの変更を構成するをご覧ください。
動的ヘッダー変数
カスタム ヘッダーには 1 つ以上の動的変数を含めることができます。
キャッシュキー ポリシー(cacheKeyPolicy.includedHeaderNames)の一部であるリクエスト ヘッダーには、1 つ以上のカスタム変数を含めることができます。他の動的変数を含むリクエスト ヘッダーは、キャッシュキーの一部にできません。
| 変数 | 説明 | リクエスト ヘッダーでサポートされている | キャッシュキーのリクエスト ヘッダーでのサポート | レスポンス ヘッダーでサポートされている | 
|---|---|---|---|---|
| cdn_cache_status | リクエスト / レスポンス パス内の各キャッシュ ノードのロケーション(最も近い空港の IATA コード)とステータスのカンマ区切りのリスト。右端の値は、ユーザーに最も近いキャッシュを表します。 | ✔ | ||
| client_city | リクエスト送信元の市区町村の名前。たとえば、カリフォルニアの Mountain View の場合は Mountain Viewです。この変数について有効な値の正規リストはありません。都市名には、US-ASCII 文字、数字、スペース、および!#$%&'*+-.^_`|~を含めることができます。 | ✔ | ✔ | |
| client_city_lat_long | リクエスト送信元の都市の緯度と経度。たとえば、Mountain View からのリクエストの場合は 37.386051,-122.083851です。 | ✔ | ✔ | |
| client_region | クライアントの IP アドレスに関連付けられる国(またはリージョン)。これは、 USやFRなどの Unicode CLDR リージョン コードです。
ほとんどの国では、このコードが ISO-3166-2 コードに直接対応しています。 | ✔ | ✔ | ✔ | 
| client_region_subdivision | サブディビジョン(クライアントの IP アドレスに関連付けられる国の県や州など)。これは、 USCAやCAONなどの Unicode CLDR サブディビジョン ID です。この Unicode コードは、ISO-3166-2 標準で定義されているサブディビジョンから派生しています。 | ✔ | ✔ | ✔ | 
| client_rtt_msec | CDN と HTTP(S) クライアント間の推定ラウンドトリップ送信時間(ミリ秒単位)。これは、ロードバランサの TCP スタックによって測定される平滑化されたラウンドトリップ時間(SRTT)パラメータです(RFC 2988 を遵守)。 | ✔ | ✔ | |
| device_request_type | クライアントが使用しているデバイスのタイプ。有効な値は次のとおりです。 DESKTOP、MOBILE、TABLET、SMART_TV、GAME_CONSOLE、WEARABLE、UNDETERMINED。 | ✔ | ✔ | |
| host | クライアント リクエストが最初に送信されたサーバーのホストとポート番号。HTTP/1.1 の場合は Hostリクエスト ヘッダーの値、HTTP/2 の場合は:authority疑似ヘッダーの値に対応します。 | ✔ | ✔ | |
| original_request_id | このレスポンスを最初に生成したリクエストに割り当てられた一意の識別子。キャッシュに保存されたレスポンスの request_idとは異なる場合にのみ入力されます。 | ✔ | ||
| origin_name | レスポンスがプロキシされた EdgeCacheOriginリソース。 | ✔ | ||
| origin_request_header | クロスオリジン リソース シェアリング(CORS)のユースケースのリクエストに含まれる送信元ヘッダーの値を反映したものになります。 | ✔ | ||
| proxy_status | レスポンス パスの中間 HTTP プロキシのリスト。値は RFC 9209 で定義されています。 EdgeCacheServiceリソースはGoogle-Edge-Cacheで表されます。レスポンスがオリジンから取得された場合、EdgeCacheOriginリソースはGoogle-Edge-Cache-Originで表されます。 | ✔ | ||
| tls_sni_hostname | RFC 6066 で定義されたサーバー名表示(TLS または QUIC handshake 中にクライアントによって提供された場合)。ホスト名は小文字に変換され、末尾のドットはすべて削除されます。 | ✔ | ✔ | |
| tls_version | SSL handshake 中にクライアントとロードバランサの間でネゴシエートされた TLS バージョン。可能な値は、 TLSv1、TLSv1.1、TLSv1.2、TLSv1.3などです。クライアントが TLS ではなく QUIC を使用して接続した場合、値は QUIC です。 | ✔ | ✔ | |
| tls_cipher_suite | TLS handshake 中にネゴシエートされた暗号スイート。値は IANA TLS 暗号スイートレジストリで定義されます(例: TLS_RSA_WITH_AES_128_GCM_SHA256)。この値は、QUIC と暗号化されていないクライアント接続の場合には空です。 | ✔ | ✔ | |
| user_agent_family | クライアントが使用しているブラウザ ファミリー。有効な値は次のとおりです。 APPLE、APPLEWEBKIT、BLACKBERRY、DOCOMO、GECKO、GOOGLE、KHTML、KOREAN、MICROSOFT、MSIE、NOKIA、NETFRONT、OBIGO、OPENWAVE、OPERA、OTHER、POLARIS、TELECA、SEMC、SMIT、USER_DEFINED。 | ✔ | ✔ | 
カスタム変数には次の考慮事項が適用されます。
- 既存のリクエスト ヘッダーとレスポンス ヘッダーは保持されますが、次のものは削除されます。 - X-User-IP
- X-Googleまたは- X-GFEを含む任意のヘッダー
 
- ヘッダーの鍵と値は、RFC 7230 に準拠している必要があります。旧式の形式は許可されません。 
- すべてのヘッダーキーは小文字です(HTTP/2 を遵守)。 
- 一部のヘッダーは統合されます。同じヘッダーキー(例: - Via)を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。 その他のヘッダー(- Set-Cookieなど)が結合されることはありません。
- いくつかのヘッダーが追加されるか、値が追加されます。 Media CDN は、 - X-Forwarded-Forなどの特定のヘッダーを常に追加、または変更します。
- Media CDN は、クライアントや送信元で設定されていたとしても、サポートされている変数を含む任意のレスポンス ヘッダーを展開します。これにより、カスタム ヘッダーの構成に加えて、クライアント(動画プレーヤーなど)または送信元のインフラストラクチャから動的ヘッダーを設定できます。 
- たとえば、前述のルールに従って、 - X-Goog-ヘッダーと- X-Amz-ヘッダーは保持され、小文字になります。
キャッシュ ステータスの値
{cdn_cache_status} ヘッダー変数は、レスポンスを提供したキャッシュの階層に対応する複数の値を返すことができます。{cdn_cache_status} ヘッダー変数を解釈する際は、次のガイドラインを考慮してください。
- ヘッダーに hitが含まれている場合、リクエストされたコンテンツはキャッシュから取得されています。
- ヘッダーに missが含まれている場合、リクエストされたコンテンツはキャッシュノードで見つからなかったため、アップストリーム ノードから取得する必要がありました。
- ヘッダーに fetchが含まれている場合、リクエストされたコンテンツはオリジンから取得されています。
- ヘッダーに - uncacheableが含まれている場合、リクエストされたコンテンツは、キャッシュ インフラストラクチャの一部またはすべてのコンポーネントでキャッシュ不可とみなされています。- ヘッダーに hitまたはmissも含まれている場合、リクエストされたコンテンツは、一部のキャッシュ コンポーネントではキャッシュ不可、他のコンポーネントではキャッシュ可能とみなされています。
- ヘッダーに hitまたはmissも含まれていない場合、リクエストされたコンテンツは、すべてのキャッシュ コンポーネントでキャッシュ不可とみなされ、このコンテンツに対するすべてのリクエストは送信元から取得されます。コンテンツが適切にキャッシュに保存されるようにするには、Media CDN の送信元の要件を確認してください。
 
- ヘッダーに 
デフォルトのヘッダー
Media CDN は、それぞれ次のリクエスト ヘッダーとレスポンス ヘッダーをオリジン リクエストとクライアント レスポンスに追加します。
| ヘッダー | 説明 | リクエスト | レスポンス | 
|---|---|---|---|
| x-request-id | 所与のリクエストの一意の識別子。この値はリクエスト ログにも jsonPayload.requestIdとして追加されるため、クライアントのリクエストとレスポンスをログエントリに関連付けることができます。 | ✔ | |
| age | キャッシュに保存されたオブジェクトの経過時間(キャッシュに存在している秒数)を返します。経過時間は、通常、オブジェクトがロングテール(シールド)キャッシュのロケーションに最初にキャッシュされた時点に基づいて計算されます。 
 | ✔ | |
| server | Google-Edge-Cacheとして設定されています。 | ✔ | |
| cdn-loop | ループを識別します。たとえば、送信元ホストがユーザー向けの(エッジ)ホストと同じである場合です。 RFC 8586 に従って、 | ✔ | |
| forwarded | 
 これらのヘッダーによって、1 つのプロキシ(または複数のプロキシ)がパス内にあるときに、接続クライアントの IP アドレスを識別できます。たとえば、IP アドレス  
 複数のクライアント側プロキシの場合、Media CDN に接続したクライアントはヘッダー値に追加される最後のアドレスになります。 | ✔ | |
| x-forwarded-for | 非構造化で事実上の  両方のヘッダーは、 | ✔ | 
ヘッダーキーは小文字で大文字と小文字を区別しないため、リクエスト ヘッダーとレスポンス ヘッダーの両方で小文字が指定されます。
エッジのポイント オブ プレゼンス(PoP)のロケーションやキャッシュ ステータス(hit、miss など)など、その他のヘッダーは、動的ヘッダー変数を使用して追加できます。