このページは Cloud Translation API によって翻訳されました。

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

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

ルートルールを構成する

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

コンソール

Google Cloud コンソールで、[Media CDN] ページに移動します。

Media CDN に移動
ルートルールを構成するサービスの [詳細] ページを開くには、サービス名をクリックします。
編集モードに切り替えるには、[編集] ボタンをクリックします。
[ルーティング] セクションに移動するには、[次へ] をクリックします。
ホストルールを少なくとも 1 つ指定します。[ホストルールを追加] をクリックします。次に、以下の操作を行います。
1. [ホスト] に、マッチングするホストを少なくとも 1 つ指定します。
2. [説明] に、ホストルールの簡単な説明を入力します。
または、ホストルールを編集するには、矢印をクリックして展開します。
ルートルールを少なくとも 1 つ指定します。[ルートのルールを追加] をクリックします。

または、ルートルールを編集するには、それぞれの行で [編集] をクリックします。
[ルートルールを編集] ペインの [優先度] に、ルートの優先度の値を設定します。
[説明] に、ルールのリストでルールを識別するのに役立つ簡単な説明を入力します。
[一致] セクションで、1 つ以上の一致条件を指定します。[一致条件を追加] をクリックします。次に、以下の操作を行います。
1. [一致タイプ] で、任意のパスの一致オプションを選択します。
2. [パスの一致] で、名前、パス、テンプレートを指定します。ワイルドカードパターンマッチングの使用を検討してください。
  
  必要に応じて、[パス値の大文字と小文字の区別を有効にする] も選択します。
3. 省略可: [ヘッダーの一致] と [クエリパラメータの一致] を選択します。次に、関連するボタンをクリックして、ヘッダーとクエリパラメータを追加します。それぞれに、名前、照合タイプ、値を指定します。
  
  詳細については、ヘッダーとクエリパラメータの一致をご覧ください。
4. 一致条件を保存するには、[完了] をクリックします。
[プライマリアクション] で、次のいずれかのオプションを選択します。
- オリジンから取得: リクエストを特定のオリジンに転送するには、このオプションを選択し、オリジンを選択します。
- URL リダイレクト: リクエストをリダイレクトするには、このオプションを選択します。次に、リダイレクトのタイプ、パス、ステータスコードを指定します。
  
  必要に応じて、[すべてのレスポンスを HTTPS にリダイレクトする] オプションまたはクエリを削除するオプションを選択します。
[詳細構成] をクリックします。
1. [ヘッダーアクション] セクションで、[項目を追加] をクリックします。
  
  アクションのタイプを選択し、名前と値のペアとしてヘッダーを指定します。次に [完了] をクリックします。
2. [ルートのアクション] セクションで、[項目を追加] をクリックします。
  
  アクションのタイプと関連するオプションを指定します。次に [完了] をクリックします。
[HTTP メソッドのフィルタリング] で、[HTTP メソッドのフィルタリングをカスタマイズする] を選択します。

次に、オリジンにプロキシする HTTP メソッドを選択します。
ルートルールを保存するには、[保存] をクリックします。
サービスへの変更を保存するには、[サービスを更新する] をクリックします。

gcloud と YAML

Media CDN 構成を YAML ファイルにエクスポートします。gcloud edge-cache services export コマンドを使用します。
```
gcloud edge-cache services export SERVICE_NAME \
    --destination=FILENAME.yaml
```
次のように置き換えます。
- SERVICE_NAME: サービスの名前
- FILENAME : YAML ファイルの名前
このページのセクションで説明されているように、必要な構成で YAML ファイルを更新します。
サービスを更新するには、YAML ファイルから Media CDN 構成をインポートします。gcloud edge-cache services import コマンドを使用します。
```
gcloud edge-cache services import SERVICE_NAME \
    --source=FILENAME.yaml
```

一致したリクエスト数

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 つです。

フィールド説明例

フィールド	説明	例
`matchRules[].fullPathMatch`	`fullPathMatch` 条件は、クエリ文字列を含まない完全な URL パスと一致します。必要に応じて、末尾のスラッシュを指定する必要があります。	`fullPathMatch: "/stream/"` の一致ルールを持つルートは、`/stream/` と一致しますが、`/stream` や `/stream/us/hls/1234.ts` とは一致しません。 `fullPathMatch` は明示的な（完全）一致です。
`matchRules[].prefixMatch`	`prefixMatch` 条件は URL パスの接頭辞、すなわち同じ文字列で始まる URL と一致します。	`prefixMatch: "/videos/"` のルールを持つルートは、`/videos/hls/58481314/manifest.m3u8` と `/videos/dash` に `/videos/` 接頭辞が含まれているため、両方に一致します。
`matchRules[].pathTemplateMatch`	`pathTemplateMatch` 条件ではワイルドカード演算子がサポートされます。これにより、複雑な URL パターンやパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。	`pathTemplateMatch: "/**.m3u8"` の一致ルールを持つルートは、`.m3u8` で終わるすべての URL パスに一致します。 `/content/en-GB/13/51491/manifest_193193.m3u8` と `/p/abc/1234/manifest_1080p5000.m3u8` の両方がこのパターンに一致します。その他の例については、パターンマッチングのセクションをご覧ください。

matchRules[].fullPathMatch

fullPathMatch 条件は、クエリ文字列を含まない完全な URL パスと一致します。必要に応じて、末尾のスラッシュを指定する必要があります。

fullPathMatch: "/stream/" の一致ルールを持つルートは、/stream/ と一致しますが、/stream や /stream/us/hls/1234.ts とは一致しません。

fullPathMatch は明示的な（完全）一致です。

matchRules[].prefixMatch

prefixMatch 条件は URL パスの接頭辞、すなわち同じ文字列で始まる URL と一致します。

prefixMatch: "/videos/" のルールを持つルートは、/videos/hls/58481314/manifest.m3u8 と /videos/dash に /videos/ 接頭辞が含まれているため、両方に一致します。

matchRules[].pathTemplateMatch

pathTemplateMatch 条件ではワイルドカード演算子がサポートされます。これにより、複雑な URL パターンやパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。

pathTemplateMatch: "/**.m3u8" の一致ルールを持つルートは、.m3u8 で終わるすべての URL パスに一致します。

/content/en-GB/13/51491/manifest_193193.m3u8 と /p/abc/1234/manifest_1080p5000.m3u8 の両方がこのパターンに一致します。

その他の例については、パターンマッチングのセクションをご覧ください。

詳細については、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 の複数の部分を照合できます。

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

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

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

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

演算子	一致	例
`*`	次のパス区切り文字 `/` までの 1 つのパスセグメントと一致します。	`/videos///*.m4s` matches `/videos/123414/hls/1080p5000_00001.m4s`.
`**`	0 個以上のパスセグメントを照合します。存在する場合は、最後の演算子にする必要があります。	`/**.mpd` matches `/content/123/india/dash/55/manifest.mpd`.
`{name} or {name=*}`	1 つのパスセグメントに一致する名前付き変数。次のパス区切り文字 `/` までの 1 つのパスセグメントと一致します。	`/content/{format}/{lang}/{id}/{file}.vtt` は `/content/hls/en-us/12345/en_193913.vtt` と一致し、`format="hls"`、`lang="en-us"`、`id="12345"`、`file="en_193913"` を変数としてキャプチャします。
`{name=videos/*}`	複数のパスセグメントに一致する名前付き変数。`videos/*` に一致するパスセグメントは、名前付き変数としてキャプチャされます。	`/videos/{language=lang/}/` は `/videos/lang/en/video.m4s` と一致し、パス変数 `language` に値 `lang/en` を入力します。
`{name=**}`	0 個以上のパスセグメントに一致する名前付き変数。存在する場合は、最後の演算子にする必要があります。	`/.m3u8` または `/{path=}.m3u8` は、拡張子までのすべてのパスセグメントを照合します。 `/videos/{file=**}` は、拡張子を含む `/videos/en-GB/def566/manifest.m3u8` と一致し、パス変数 `file="en-GB/def566/manifest.m3u8` をキャプチャします。

注:

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} 変数は、オリジンのディレクトリ構造と一致しないため、明示的に省略します。

この例では、次のようになります。

/us/en/hls/123139139/segment_00001.ts の受信リクエスト URL が pathTemplateMatch と一致し、送信元に送信される前に /123139139/hls/segment_00001.ts に書き換えられます。
受信リクエスト URL /us/123139139/master.m3u8 は pathTemplateMatch と一致せず、HTTP 404 (Not Found) ステータスコードを受信します。
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt の受信リクエスト URL も 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 メソッドのみを送信元にプロキシし、送信元を変更できるメソッドを除外します。

オリジンにプロキシするメソッドを指定することで、特定のルートルールのデフォルトの動作をオーバーライドできます。GET、HEAD、OPTIONS の他に、Media CDN は PUT、POST、DELETE、PATCH をサポートしています。

Media CDN は、GET、HEAD、OPTIONS などの安全な HTTP メソッドを使用するリクエストに対してのみ、再試行またはフェイルオーバーを試みます。

ルートルールのメソッドのセットのサポートを構成するには、各メソッドの 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 の複数の表現を単一の正規表現に結合する方法について説明します。

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

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

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

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

書き換えとリダイレクト

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

リクエスト URL の書き換え

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

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

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

フィールド説明

フィールド	説明
`urlRewrite.pathPrefixRewrite`	パスを書き換え、リクエストに一致する `prefixMatch` で指定された接頭辞を削除します。 1 つのルートルールで指定できるのは、`pathPrefixRewrite` または `pathTemplateRewrite` のいずれか 1 つのみです。
`urlRewrite.pathTemplateRewrite`	`pathTemplateRewrite` は、同じルートの対応する `pathTemplateMatch` 一致ルールでのみ使用できます。 1 つのルートルールで指定できるのは、`pathPrefixRewrite` または `pathTemplateRewrite` のいずれか 1 つのみです。
`urlRewrite.hostRewrite`	リクエストを送信元サーバーに送信する前にホストを書き換えます。

urlRewrite.pathPrefixRewrite

パスを書き換え、リクエストに一致する prefixMatch で指定された接頭辞を削除します。

1 つのルートルールで指定できるのは、pathPrefixRewrite または pathTemplateRewrite のいずれか 1 つのみです。

urlRewrite.pathTemplateRewrite

pathTemplateRewrite は、同じルートの対応する pathTemplateMatch 一致ルールでのみ使用できます。

1 つのルートルールで指定できるのは、pathPrefixRewrite または pathTemplateRewrite のいずれか 1 つのみです。

urlRewrite.hostRewrite リクエストを送信元サーバーに送信する前にホストを書き換えます。

注:

書き換えられた 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 値を次の表に示します。

リダイレクトのレスポンスコード	HTTP ステータスコード
`MOVED_PERMANENTLY_DEFAULT`	HTTP 301（恒久的に移動）
`FOUND`	HTTP 302 (Found)
`SEE_OTHER`	HTTP 303（他を参照）
`TEMPORARY_REDIRECT`	HTTP 307（一時的なリダイレクト）
`PERMANENT_REDIRECT`	HTTP 308（恒久的なリダイレクト）

注:

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

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

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

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

gcloud

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

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

このコマンドは、サービスの説明を返します。requireTls は true に設定されています。

  name: MY_SERVICE
  requireTls: true

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

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

Media CDN は、 Google Cloudの外部にある一般公開の HTTP エンドポイント（AWS S3 ストレージバケット、Azure Blob Storage、その他のストレージプロバイダなど）への接続をサポートしています。これは、マルチクラウドアーキテクチャを使用している場合や、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 ヘッダーのセットを使用してこれらのルールを定義します。Access-Control-Allow-Origin、Access-Control-Max-Age、Access-Control-Allow-Headers など、レスポンスで一般的な CORS ヘッダーを設定できます。これらのヘッダーを使用すると、メディア 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 を含めるかどうか）であることを示す必要があります。

別の例として、CORS リクエストで送信元として stream.example.com を許可し、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 ポリシーに含まれるフィールドを示します。

フィールド	説明	例
allowOrigins	`Access-Control-Allow-Origins` レスポンスヘッダーを設定します。これにより、ブラウザ環境でクロスオリジンリクエストを送信できる送信元が指定されます。たとえば、動画コンテンツが `https://video.example.com` から提供され、ユーザー向けのポータルが `https://stream.example.com` から提供されている場合、`https://stream.example.com` を許可される送信元として追加します。	`Access-Control-Allow-Origins: https://stream.example.com`
maxAge	`Access-Control-Max-Age` レスポンスヘッダーを設定します。これにより、ブラウザクライアントが CORS プリフライトリクエストに対するレスポンスをキャッシュに保存する期間が秒単位で指定されます。最大値（86, 400 秒）が指定されていても、ブラウザによっては 2 時間以下に制限されることがあります。	`Access-Control-Max-Age: 7200`
allowMethods	`Access-Control-Allow-Methods` レスポンスヘッダーを設定します。これにより、リソースへのアクセスが許可された HTTP メソッドが指定されます。デフォルトでは、Media CDN は `GET`、`HEAD`、`OPTIONS` のメソッドのみをサポートします。他のメソッドのサポートを構成するには、ルートメソッドをご覧ください。	`Access-Control-Allow-Methods: GET, OPTIONS, HEAD`
allowHeaders	`Access-Control-Allow-Headers` ヘッダーを設定します。これにより、CORS リクエストで送信できるヘッダーが決まります。動画プレーヤーは、クロスオリジンで動画コンテンツをリクエストするときに一部のレスポンスヘッダーにアクセスする必要があるため、多くの場合これが必須です。	`Access-Control-Allow-Headers: Content-Type, If-Modified-Since, Range, User-Agent`
exposeHeaders	`Access-Control-Expose-Headers` レスポンスヘッダーを設定します。これにより、クライアントサイドの JavaScript がアクセスできるヘッダーが決まります。動画プレーヤーは、クロスオリジンでコンテンツをリクエストするときに、動画コンテンツの特定のレスポンスヘッダーにアクセスする必要がある場合があるため、多くの場合これが必須です。	`Access-Control-Expose-Headers: Date, Cache-Status, Content-Type, Content-Length`
allowCredentials	`Access-Control-Allow-Credentials` レスポンスヘッダーを設定します。これにより、クライアントサイドの JavaScript で、認証情報を含むリクエストのレスポンスを検査できます。 false に設定されている場合、このヘッダーは省略されます。	`Access-Control-Allow-Credentials: true`
disabled	`corsPolicy` を削除せずに無効にします。プリフライトの `OPTIONS` リクエストは、送信元にプロキシされます。	該当なし

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）証明書を設定する。
コンテンツへのアクセスを認証するように署名付きリクエストを構成します。
Terraform を使用して EdgeCacheService リソースを構成する方法の詳細については、Terraform レジストリのドキュメントをご覧ください。