サービス ルートを構成する

メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。

ルートルールを構成する

Media CDN サービスのルートルールを構成する。

一致したリクエスト数

Media CDN 構成には、EdgeCacheService リソースのルーティングセクションで定義されるルートのセットが含まれます。このルートは（少なくとも）ホストに基づいてリクエストと一致します。トラフィックが送信元に転送される仕組みの詳細については、HostRule と PathMatcher をご覧ください。各ルートでは、独自の CDN 構成、書き換え、リダイレクト、CORS ポリシー、カスタム HTTP ヘッダー、送信元マッピングを定義できます。 ルート間で起点を共有できます。

たとえば、マニフェストに対するリクエストを特定の送信元にルーティングし、有効期間が短いキャッシュ TTL とネガティブ キャッシュ ポリシーを定義できます。ヘッダーとクエリ パラメータを使用して特定のマニフェスト タイプやユーザーを分割して、セグメントに対するリクエストを別の送信元に分割できます。

次の例は、ホスト media.example.com の特定のヘッダー、クエリ パラメータ、パス接頭辞に一致するリクエストを転送する方法を示しています。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      origin: staging-live-origin
      matchRules:
      - prefixMatch: /vod/
        headerMatches:
        - headerName: "x-staging-client"
          presentMatch: true
        queryParameterMatches:
        - name: "live"
          exactMatch: "yes"
      routeAction:
        cdnPolicy:
          defaultTtl: 5s

パスマッチング

Media CDN は、完全（正確な）マッチング、プレフィックス マッチング、ワイルドカード パス マッチングをサポートしています。 パス マッチングは、ホスト、ヘッダー、クエリ パラメータベースのマッチングと組み合わせて、きめ細かいリクエスト ルーティング ルールを作成できます。

URL パスでマッチングする方法は、次の 3 つです。

詳細については、MatchRule の API 仕様をご覧ください。

たとえば、/stream/ で始まるすべてのリクエストを照合するには、次のようなルートルールを作成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      - prefixMatch: /stream/

この例では、末尾のスラッシュを一致ルールに明示的に含めています。

• media.example.com/stream/id/1234/hls/manifest.m3u8 へのリクエストは、このルートと一致します。
• media.example.com/stream-eu/id/4567/hls/manifest.m3u8 へのリクエストは、このルートに一致しません。

2 番目のケースでは、別のルートまたはキャッチオール ルートが構成されている場合を除き、Media CDN は HTTP 404 エラーを返します。

接頭辞が類似するルートで優先度がどのように機能するかについては、ルートの優先度と順序指定のセクションをご覧ください。

パターン（ワイルドカード）のマッチング

パターン マッチングでは、ワイルドカード構文を使用して、部分的な URL や接尾辞（ファイル拡張子）など、URL の複数の部分を照合できます。

1 つ以上のパスセグメントを pathTemplateMatch フィールドの名前付き変数に関連付けて、pathTemplateRewrite フィールドで URL を書き換える際にそれらの変数を参照することもできます。これにより、リクエストが送信元に送信される前に URL セグメントの順序を変更して削除できます。

次の例は、2 つの異なる URL 接尾辞に対する照合方法を示しています。

# EdgeCacheService.routing.pathMatchers[]
    routeRules:
    - priority: 1
      description: "Match video segments"
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: prod-video-storage

サポートされている構文は次のとおりです。

注:

• URL を書き換えない場合は、よりシンプルな * 演算子と ** 演算子を使用します。
• 変数を使用してパスセグメントをキャプチャする場合、変数でキャプチャされていない URL の部分は、後続の pathTemplateRewrite で参照できません。例については、パス変数のキャプチャのセクションをご覧ください。
• 同じルートの pathTemplateMatch に存在しない変数を、後続の pathTemplateRewrite で参照することはできません。
• 変数では大文字と小文字が区別され、{FORMAT}、{forMAT}、{format} は異なる変数と値を表します。
• マッチには最大 10 個のオペレーター（ワイルドカードまたは変数）を指定できます。pathTemplateMatch フィールドと pathTemplateRewrite フィールドは 255 文字以下にする必要があります。

例: ファイル拡張子に基づく一致

次の例は、ワイルドカード演算子の一般的なユースケースを示しています。接尾辞までのすべてのパスセグメントを照合します。

この場合は、次の操作を行います。

• マニフェストの送信元から .m3u8 と .mpd で終わる動画マニフェスト（プレイリスト）を取得します。これらのレスポンスは定期的に変更されるため、短い（5 秒）TTL を適用します。
• セグメントの送信元から .ts と .m4s で終わる動画セグメントを取得し、これらのレスポンスに長い（1 日）TTL を適用します。

このアプローチは、SSAI（サーバーサイド広告挿入）サービスや DAI（ダイナミック広告挿入）サービスを使用する場合や、マニフェストが数秒ごとに更新されるライブ動画でよく使用されます。

次の構成は、これをサポートするように Media CDN ルーティングを構成する方法を示しています。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # the first route only matches video manifests
    - priority: 1
      matchRules:
      - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments
      - pathTemplateMatch: "/**.mpd"
      origin: manifest-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 5s
    # the second route matches video segments, fetches them
    # from a separate origin server, caching them for a longer
    # duration (1 day).
    - priority: 2
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: segment-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 86400s

例: パス変数をキャプチャする

次の例は、名前付き変数を使用して 1 つ以上のパスセグメントを記述する方法を示しています。

これらの変数は、pathTemplateRewrite で使用して、リクエストが送信元に送信される前にパスを書き換えたり、複雑な pathTemplateMatch を自己記述型にしたりできます。

routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      # Matches a request of "/us/en/hls/123139139/segments/00001.ts"
      - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}"
      origin: my-origin
      routeAction:
        urlRewrite:
          # Rewrites to "/123139139/hls/segments/00001.ts"
          pathTemplateRewrite: "/{id}/{format}/{file}"

具体的な内容は以下のとおりです。

• 各 {name} 変数は 1 つのパスセグメントをキャプチャします。パスセグメントは、URL パス内の / ペア（「スラッシュ」）間のすべての文字です。
• {name=**} の変数は、残りのすべてのパスセグメントをキャプチャします。この場合、segments/00001.ts と master.m3u8 の両方に一致します。
• 同じルートの pathTemplateRewrite で、pathTemplateMatch でキャプチャした変数の一部を参照します。{country} 変数と {lang} 変数は、オリジンのディレクトリ構造と一致しないため、明示的に省略します。

この例では、次のことが行われます。

• 受信したリクエスト URL /us/en/hls/123139139/segment_00001.ts は pathTemplateMatch と一致し、送信元に送信される前に /123139139/hls/segment_00001.ts に書き換えられます。
• 受信リクエスト URL /us/123139139/master.m3u8 は pathTemplateMatch と一致せず、HTTP 404 (Not Found) レスポンスを受信します。
• 受信リクエスト URL /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt も pathTemplateMatch と一致し、送信元に送信される前に /c966cbbe6ae3/dash/subtitle_00001.vtt に書き換えられます。

ワイルドカード マッチングと URL の書き換えの相互運用の詳細については、書き換えのセクションをご覧ください。

ホスト マッチング

各サービスは複数のホスト名で照合できます。各ホスト名には、独自のルートグループ（パスマッチャー）が含まれています。最も一般的なケースでは、サービスのすべてのホスト名は、単一のホストリストと単一のパスマッチを持つ単一の共有ルートセットにマッピングされます。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # list of routes for the configured hosts
    - priority: 999
      matchRules:
      - prefixMatch: /
      origin: DEFAULT_ORIGIN

一致しないホストには、デフォルトの HTTP 404 ページが配信されます。すべてのホストを許可するには、ワイルドカード文字 * を hostRules[].hosts[] エントリとして含めます。

ルートのグループを定義することもできます（国別、ライブとオンデマンドなど）。各サービスには 1 つのセキュリティ ポリシーがあるため、通常は、マーケット（地域）またはワークロードごとに 1 つのサービスを用意することをおすすめします。

注:

• ポートを含むホスト（または HTTP/2 :authority）ヘッダーは、構成されたホストと暗黙的に照合されます。ポートを明示的に指定する必要はありません。
• リクエストが HTTP 経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com と us.vod.example.com:80 と一致します。
• リクエストが HTTPS（TLS）経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com:443 と一致します。

詳細については、HostRule の API 仕様をご覧ください。

ヘッダーとクエリ パラメータの一致

特定のヘッダー名とクエリ パラメータ名、およびヘッダー値の有無（接頭辞、接尾辞、完全一致）に基づいて一致するようにルートを構成できます。

クエリ パラメータとヘッダーのマッチングは論理演算「AND」です。リクエストは、指定されたルートに一致するために、すべてのクエリ パラメータとヘッダーキー（および指定されている場合は値）と一致する必要があります。

たとえば、特定のヘッダー フィールド名とヘッダー値を持つリクエストを alternate-origin という名前の送信元に転送する場合は、routeRules[].matchRules[].headerMatches[] 内で一致条件を構成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: alternate-origin
      matchRules:
      - prefixMatch: "/videos/"
        headerMatches:
        - headerName: "x-device-name"
          exactMatch: "roku"

この例では、URL の先頭に /videos/ があり、x-device-name: roku ヘッダーが付いたリクエストがこのルートに一致します。このヘッダー名がないリクエストや、値が異なるリクエストは、このルートに一致しません。

詳細については、HeaderMatch の API 仕様をご覧ください。

同様に、クエリ パラメータと照合するには、次のように 1 つ以上の queryParameterMatches を指定します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: eu-live-origin-prod
      matchRules:
      - prefixMatch: "/videos/"
        queryParameterMatches:
        - name: "playback_type"
          exactMatch: "live"
        - name: "geo"
          exactMatch: "eu"

この例では、https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu のクライアント リクエストがこのルートに一致します。

詳細については、QueryParameterMatcher の API 仕様をご覧ください。

キャッチオール（デフォルト）ルートを定義する

デフォルトでは、リクエストが構成済みのルートに一致しない場合、Media CDN は HTTP 404 (Not Found) エラーを返します。

特定の pathMatcher（ルートのコレクション）に対してキャッチオールルートを構成するには、次の手順を行います。

• 最も低い優先度（最大の数値）の routeRule を作成します。たとえば、999 は、可能な限り低いルート優先度です。
• 接頭辞が / の matchRule を構成します（すべてのリクエストパスと一致します）。
• ルートに origin または urlRedirect を構成します。

たとえば、一致しないすべてのリクエストを my-origin という名前のデフォルトの送信元に転送するキャッチオール ルートを構成するには、次のように priority: 999 と / の matchRules[].prefixMatch を含む新しいルートを作成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 999
      origin: my-origin
      matchRules:
      - prefixMatch: /

必要に応じて、送信元の取得前に URL を書き換えたり、リクエストをそのまま送信元に送信する代わりに、デフォルトのページ（ランディング ページなど）にリダイレクトしたりできます。

ルートの優先度と順序指定

routeRules[] の配列内の各ルートに priority を関連付ける必要があります。

より具体的なルートには、高い優先度（小さい数値）を設定する必要があります。優先度 1 を持つ /stream/ の接頭辞と一致するルートにより、より具体的な優先度 5 を持つ /stream/live/eu/ のルートは、どのリクエストとも一致しません。

• 優先度が最も高いルートは「1」、最も低いルートは「999」です。
• 同じ優先度のルートルールを複数構成することはできません。各ルールの優先度は、0～2147483647 の番号に設定する必要があります。
• キャッチオールルートを定義すると、一致しないすべてのリクエストをデフォルトの送信元に送信するか、ランディング ページやエンドポイントにリダイレクトできます。

次の例では、/live/ ルートが優先度が高いため、/live/us/ ルートは一致しません。

routeRules:
- priority: 1
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "U.S based live streams"
  matchRules:
  # This would never be matched, as the /live/ prefixMatch at priority 1
  # would always take precedence.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

この問題に対処するには、より高い優先度でより具体的な（長い）ルートを設定します。

routeRules:
- priority: 1
  description: "U.S based live streams"
  matchRules:
  # The more specific (longer) match is at a higher priority, and now
  # matches requests as expected.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

これにより、より具体的なルートがリクエストに正しく一致するようになります。/live/eu/ の接頭辞が付いたリクエストは、引き続き優先度 2 で /live/ ルートに適用されます。

メソッドのフィルタリング

デフォルトでは、Media CDN は GET、HEAD、OPTIONS メソッドのみを送信元にプロキシし、送信元を変更できるメソッドを除外します。

特定のルートルールに対してこのデフォルトの動作をオーバーライドするには、送信元にプロキシするメソッドを指定します。Media CDN は、GET、HEAD、OPTIONS のほか、PUT、POST、DELETE、PATCH もサポートしています。

ルートルールのメソッドセットのサポートを構成するには、メソッドごとに allowed_methods 値を持つ routeMethods セクションを指定します。

routeRules:
- priority: 5
  description: "Video uploads"
  routeMethods:
    allowedMethods: ["PUT", "POST", "OPTIONS"]
  matchRules:
  - pathTemplateMatch: "/uploads/**.ts"
  origin: prod-video-storage
- priority: 10
  description: "Video serving"
  routeMethods:
    allowedMethods: ["GET", "HEAD"]
  matchRules:
  - pathTemplateMatch: "/videos/**.ts"
  origin: prod-video-storage

パスの正規化

パスの正規化では、特定のシナリオで Media CDN が URL の複数の表現を 1 つの正規表現に統合する方法について説明します。

パスの正規化は、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを想定する送信元の送信元エラーを軽減することで、キャッシュ ヒット率を直接改善できます。

受信リクエストは次のように正規化されます。

• 連続する複数のスラッシュは 1 つのスラッシュに統合されます。たとえば、URL パス /videos///12345/manifest.mpd は /videos/12345/manifest.mpd に正規化されます。
• パスセグメントは、RFC 3986 セクション 6.2.2.3 に従って正規化されます。 たとえば、パス /a/b/c/./../../g は、RFC 3986 で定義されている「ドットセグメントを削除」アルゴリズムに基づいて /a/g に正規化されます。この正規化は、キャッシュのチェックやリクエストの送信元への転送の前に行われます。
• リクエストはパーセントで正規化されません。たとえば、パーセント スラッシュ（%2F）エンコードを含む URL の場合、エンコードされていない形式にデコードされません。

URL の大文字と小文字は区別されません。多くの URL には、署名付きリクエストトークンを含む URL など、大文字と小文字が区別される base64 エンコードが含まれています。

書き換えとリダイレクト

以降のセクションでは、リクエストの書き換えとリダイレクトの構成方法の例を示します。

リクエスト URL の書き換え

Media CDN は、ホストとパスの書き換えをサポートしています。書き換えは、オリジンに送信される URL を変更し、必要に応じてホストとパスを変更できるようにします。ホストとパスの書き換えはルートレベルで行われるため、パス、クエリ パラメータ、リクエスト ヘッダーなど、任意のマッチング条件に基づいて、書き換えられる特定のリクエストを定義できます。

詳細については、RouteAction.UrlRewrite の API 仕様をご覧ください。

リクエストを書き換える方法は次の 3 つです。

注:

• 書き換えられた URL ではキャッシュキーは変更されません。キャッシュキーは、クライアントが送信したリクエスト URL に基づきます。
• 書き換えは、ルートの照合と署名付きリクエストの検証の後に実行されます。ルートは別の一致ルールに対して再照合されません。

例: パス接頭辞を削除する

たとえば、クライアント リクエスト URL を /vod/videos/hls/1234/abc.ts から /videos/hls/1234/abc.ts に書き換える（パスから /vod を削除する）には、pathPrefixRewrite 機能を使用します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/vod/videos/"
      routeAction:
        urlRewrite:
          pathPrefixRewrite: "/videos/"

pathPrefixRewrite は、matchRules[].prefixMatch で一致したパス プレフィックス全体を pathPrefixRewrite の値に置き換えることで機能します。

ホスト名を書き換える（cdn.example.com を my-bucket.s3.us-west-2.amazonaws.com に書き換えるなど）には、次のように構成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/videos/"
      routeAction:
        urlRewrite:
          hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"

この場合、送信元のリクエスト URL は cdn.example.com/videos/* から my-bucket.s3.us-west-2.amazonaws.com/videos/* に変更されます。 1 つのルート内でホストとパスの両方の書き換えを組み合わせることもできます。

例: 変数を使用して URL を書き換える

pathTemplateMatch と pathTemplateRewrite を使用して受信リクエスト URL の一部を書き換えるには、変数の取得のセクションをご覧ください。

リクエストをリダイレクトする

Media CDN は、次の 3 種類のリダイレクトをサポートしています。

• ホスト リダイレクト: パスとクエリ パラメータは変更せずに、ホスト（ドメイン）のみをリダイレクトします。
• パス リダイレクト: パス全体を置き換えます。
• パス接頭辞リダイレクト: 一致する接頭辞のみを置き換えます。

リダイレクトはデフォルトで HTTP 301 (Moved Permanently) ですが、ルートごとに異なるリダイレクト ステータス コードを返すように構成できます。

次の構成は、https://cdn.example.com/on-demand/* にアクセスしたユーザーを https://cdn.example.com/streaming/* にリダイレクトする接頭辞ベースのリダイレクトの例です。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      matchRules:
      - prefixMatch: "/on-demand/"
      urlRedirect:
        # The prefix matched in matchRules.prefixMatch is replaced
        # by this value
        prefixRedirect: "/streaming/"
        redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307

この例では、リダイレクトを一時リダイレクトに変更して、クライアント（ブラウザなど）がキャッシュに保存しないようにしています。これは、近い将来変更する予定がある場合に便利です。

サポートされている redirectResponseCode 値は次の表に示します。

注:

• ルートは、トラフィックを送信元に転送するか、リダイレクトをクライアントに返すことができます。origin フィールドと urlRedirect フィールドの両方を同時に設定することはできません。
• HTTPS にリダイレクトするルートには、少なくとも 1 つの SSL 証明書がサービスにアタッチされている必要があります。

詳細については、RouteRule.UrlRedirect の API 仕様をご覧ください。

すべてのリクエストを HTTPS にリダイレクトする

すべてのリクエストを HTTP ではなく HTTPS にリダイレクトするには、すべてのクライアント リクエストを HTTPS に自動的にリダイレクトするように各サービスを構成します。HTTP 経由で接続しているクライアントは、「http://」の代わりに「https://」を使用して同じ URL に設定した Location ヘッダーで HTTP 301 (Permanent Redirect) レスポンスを送信します。

gcloud edge-cache services update MY_SERVICE \
    --require-tls

Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

  name: MY_SERVICE
  requireTls: true

Strict-Transport-Security ヘッダーをレスポンス ヘッダーとして設定し、クライアントが常に HTTPS 経由で直接接続するように指示することもできます。

サードパーティのストレージ バックエンドを使用する

Media CDN は、AWS S3 ストレージ バケット、Azure Blob Storage、その他のストレージ プロバイダなど、Google Cloud の外部にある一般公開されている HTTP エンドポイントへの接続をサポートしています。これは、マルチクラウド アーキテクチャを使用している場合や、Storage Transfer Service を使用して Cloud Storage にデータを移行していない場合に役立ちます。

AWS S3 で仮想ホストバケットを構成する最小限のオリジン構成:

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

EdgeCacheService リソースに構成されたホスト名と一致するバケット名を使用していない場合は、このオリジンに関連付けられたルートのホスト書き換えも構成する必要があります。それ以外の場合は、送信元から取得するときに、クライアント リクエストによって設定された Host ヘッダーが使用されます。

たとえば、パス接頭辞が /legacy/ のすべてのリクエストを外部バケットにマッピングするには、送信元リクエストからこの接頭辞を削除するように hostRewrite と pathPrefixRewrite の両方を構成します。

routeRules:
  - description: legacy backend
    matchRules:
    - prefixMatch: "/legacy/"
    routeAction:
      urlRewrite:
        hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com
        pathPrefixRewrite: /
      cdnPolicy:
        cacheMode: CACHE_ALL_STATIC
        defaultTtl: 3600s

送信元リクエストでホストヘッダーが設定される方法の詳細については、送信元リクエスト ヘッダーのドキュメントをご覧ください。

クロスオリジン リソース シェアリング（CORS）

クロスオリジン リソース シェアリング（CORS）は、クロスオリジン リクエストを安全に行うためのブラウザ中心のアプローチです。CORS ポリシーを使用すると、ルートごとのポリシーに基づいて Access-Control-Allow-Origins などの CORS ヘッダーを自動的に設定できます。

CORS の構成

Media CDN では、EdgeCacheService のルートで CORS ポリシーを定義できます。

CORS ポリシーでは、共通の HTTP ヘッダーのセットでこれらのルールを定義します。レスポンスで一般的な CORS ヘッダー（Access-Control-Allow-Origin、Access-Control-Max-Age、Access-Control-Allow-Headers など）を設定できます。これらのヘッダーを使用すると、メディア CD サービスへのクロスオリジン呼び出しが可能になります。これらは、ウェブサイトのフロントエンドとは異なるドメイン（オリジン）でホストされている可能性があるため、明示的に許可されないクロスオリジン リクエストが阻止される場合があります。

たとえば、player.example.com と api.example.com は（ブラウザの意味で）異なる送信元であり、フロントエンド アプリケーションに api.example.com にリクエストを送信して次の再生リストを取得するか、関連コンテンツのリストを更新するようリクエストできます。同様に、player.example.com は cdn.example.com に連絡して動画再生リストと動画セグメントを取得する必要があります。 cdn.example.com はこれが問題ないこと、および player.example.com が allowed origin および他のルール（許可されるヘッダー、Cookie を含めるかどうか）であることを示す必要があります。

別の例として、stream.example.com を送信元として許可し、CORS リクエストで X-Client-ID ヘッダーを許可する場合は、次のようにルートで corsPolicy を構成できます。

corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders:
["X-Client-ID"]

corsPolicy は EdgeCacheService 内の routing.pathMatchers[].routeRules[].routeAction.corsPolicy で構成されます。各 routeRule は、必要に応じて異なる corsPolicy を定義できます。また、まったく定義しないこともできます。

corsPolicy 値を定義し、同じ名前のルートで responseHeadersToAdd フィールドを使用してカスタム レスポンス ヘッダーも設定すると、カスタム レスポンス ヘッダーが優先され、corsPolicy の値の代わりに使用されます。

送信元レスポンスで HTTP ヘッダーが設定され、corsPolicy 値が設定されている場合、代わりに corsPolicy 値が使用されます。値は圧縮または結合されません。これにより、無効なヘッダー値をクライアントに送信したり、意図したよりも許容度の高いポリシーを意図せず設定したりすることを回避します。

特別な {origin_request_header} には、クライアント リクエストの Origin HTTP ヘッダーが入力されます。これは、Access-Control-Allow-Origin ヘッダーのルートでカスタム レスポンス ヘッダー値として設定できます。

詳細については、RouteAction.CORSPolicy の API 仕様をご覧ください。

CORS ポリシーのフィールド

次の表に、CORS ポリシーに含まれるフィールドを示します。

corsPolicy の例

次の構成例は、基本的な corsPolicy 構成を示しています。

routeRules:
- priority: 1
  matchRules:
  - prefixMatch: /stream/
  routeAction:
    cdnPolicy:
      defaultTtl: 3600s
    corsPolicy:
      allowOrigins:
      - "https://stream.example.com"
      - "https://stream-staging.example.com"
      maxAge: 86400s # some browsers might only honor up to 7200s or less
      allowMethods:
      - "GET"
      - "HEAD"
      - "OPTIONS"
      allowHeaders:
      - "Content-Type"
      - "If-Modified-Since"
      - "Range"
      - "User-Agent"
      exposeHeaders:
      - "Content-Type"
      - "Content-Length"
      - "Date"

ルーティングのトラブルシューティング

一部のリクエストで一致する結果が取得されない、またはエラーが返される場合は、次の点を確認します。

• ルートには、prefixMatch、fullPathMatch、pathTemplateMatch のいずれか 1 つが定義された matchRule が必要です。これらのフィールドのいずれかを含めない場合、API はエラーを返します。
• 各ルートの priority が正しく設定されていることを確認します。より具体的な（長い）ルートは、より短く広範なルート一致よりも優先度が高くする必要があります。
• デフォルトでは、GET、HEAD、OPTIONS リクエストのみがサポートされています。他のメソッドのサポートを構成するには、ルート メソッドをご覧ください。特定のルートで有効になっていないメソッドは、HTTP 405 (Method Not Allowed) エラーで拒否されます。
• GET リクエストではリクエスト本文が許可されないため、本文を含む HTTP GET リクエストまたはトレイラーが含まれるリクエストは、HTTP 400 エラーで拒否されます。
• クエリ パラメータとヘッダーのマッチングは論理演算「AND」です。指定されたルートに一致するには、リクエストがすべてのクエリ パラメータまたはヘッダーキー（および指定されている場合は値）と一致する必要があります。

次のステップ

• キャッシュの構成に関するドキュメントを確認します。
• さまざまな送信元に接続する方法を理解する。
• サービスの TLS（SSL）証明書を設定する。
• コンテンツへのアクセスを認証するように署名付きリクエストを構成します。