メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。
一致したリクエスト数
Media CDN 構成には一連のルートが含まれます。このルートは、少なくともホストとパスに基づいてリクエストと一致し、トラフィックを送信元に転送します。 各ルートでは、独自の CDN 構成、書き換え、リダイレクト、CORS ポリシー、カスタム HTTP ヘッダー、送信元のマッピングを定義できます。ルートでは送信元を共有できます。
たとえば、マニフェストに対するリクエストを特定の送信元にルーティングし、有効期間が短いキャッシュ TTL とネガティブ キャッシュ ポリシーを定義できます。セグメントのリクエストは、ヘッダーとクエリ パラメータを使用して特定のマニフェスト タイプやユーザーを分割することで、別の送信元に分割できます。
次の例は、特定のヘッダー、クエリ パラメータ、パス接頭辞と一致するリクエストをルーティングする方法を示しています。
pathMatchers: - name: 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 パスと一致します。必要に応じて、末尾にスラッシュを指定する必要があります。 |
|
matchRules[].prefixMatch
|
prefixMatch 条件は URL パス接頭辞と一致します。同じ文字列で始まる URL が一致します。 |
|
matchRules[].pathTemplateMatch
|
pathTemplateMatch 条件ではワイルドカード演算子がサポートされているため、複雑な URL パターンとパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。
|
一致ルールが
その他の例については、パターン マッチングをご覧ください。 |
たとえば、/stream/
で始まるすべてのリクエストを照合するには、次のようなルートルールを作成します。
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: routes pathMatchers: - name: 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 個以上のパスセグメントに一致する名前付き変数。 存在する場合は、最後の演算子にする必要があります。 |
|
注:
- URL を書き換えない場合は、より単純な
*
演算子と**
演算子を使用します。 - 変数を使用してパス コンポーネントをキャプチャする場合、URL の変数でキャプチャされない部分は後続の
pathTemplateRewrite
で参照できません。例については、パス変数のキャプチャをご覧ください。 - 同じルートの
pathTemplateMatch
に存在しない後続のpathTemplateRewrite
の変数を参照できません。 - 変数は大文字と小文字が区別されます。
{FORMAT}
、{forMAT}
、{format}
はそれぞれ異なる変数と値を表します。 - 1 つの一致で最大 5 つの演算子(ワイルドカードまたは変数)を指定できます。
pathTemplateMatch
フィールドとpathTemplateRewrite
フィールドは 256 文字以下にする必要があります。
例: ファイル拡張子を照合する
次の例は、ワイルドカード演算子の一般的なユースケースを示しています。ユースケースは、すべてのパス コンポーネントをサフィックスまで照合します。
この場合、次の操作を行います。
- マニフェストの送信元から
.m3u8
と.mpd
で終わる動画マニフェスト(再生リスト)を取得します。これらのレスポンスは定期的に変更されるので、レスポンスに短い(5 秒間)TTL を適用します。 - セグメントの送信元から
.ts
と.m4s
で終わる動画セグメントを取得し、これらのレスポンスにさらに長い(1 日の)TTL を適用します。
このアプローチは、SSAI(サーバー側広告インジェクション)または DAI(ダイナミック広告挿入)サービスを使用する場合や、マニフェストが数秒ごとに更新されるライブ動画の場合によく使用されます。
次の構成は、これをサポートするようにメディア CDN ルーティングを構成する方法を示しています。
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: routes pathMatchers: - name: 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 つ以上のパス コンポーネントを記述する方法を示しています。
これらの変数は、送信元に送信される前にパスを書き換えたり、複雑な pathTemplateMatch
の自己記述を作成したりするために pathTemplateRewrite
で使用できます。
routing: hostRules: - hosts: - media.example.com pathMatcher: routes pathMatchers: - name: 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
と一致せず、HTTP404 (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: routes pathMatchers: - name: 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
と一致します。
ヘッダーとクエリ パラメータで照合
特定のヘッダーやクエリ パラメータ名、およびヘッダー値(プレフィックス、サフィックス、完全一致)の存在と一致するようにルートを構成できます。
クエリ パラメータとヘッダー マッチングは論理「AND」です。リクエストがすべてのルート クエリと一致するには、すべてのクエリ パラメータとヘッダーキー(および指定された場合は値)と一致する必要があります。
たとえば、特定のヘッダー フィールド名とヘッダー値を含むリクエストを alternate-origin
という名前の送信元にルーティングする場合は、routeRules[].matchRules[].headerMatches[]
内で一致条件を構成します。
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: routes pathMatchers: - name: routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
この例では、URL の先頭が /videos/
で、x-device-name: roku
ヘッダーがあるリクエストがこのルートと一致します。このヘッダー名が含まれていないリクエスト、または異なる値のリクエストは、このルートと一致しません。
同様に、クエリ パラメータと照合するには、次のように 1 つ以上の queryParameterMatches
を指定します。
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: routes pathMatchers: - name: 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
のクライアント リクエストがこのルートと一致します。
キャッチオール(デフォルト)ルートを定義する
デフォルトでは、リクエストが構成されたルートと一致しない場合、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: routes pathMatchers: - name: 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 が URL の複数の表現を特定のシナリオで単一の正規表現に結合する方法を表します。
パスの正規化によりキャッシュ ヒット率を直接改善するには、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを予期する送信元のエラーの原因を軽減します。
受信リクエストは、次のように正規化されます。
- 複数のスラッシュは、1 つのスラッシュに統合されます。たとえば、
/videos///12345/manifest.mpd
という URL パスは/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 が変更され、必要に応じてホストとパスを変更できます。ホストとパスの書き換えはルートレベルで行われるため、マッチャーに基づいて、パス、クエリ パラメータ、リクエスト ヘッダーなど、どのリクエストを書き換えるかを定義できます。
リクエストを書き換えるには、次の 3 つの方法があります。
フィールド | 説明 |
---|---|
urlRewrite.pathPrefixRewrite
|
リクエストに一致する
1 つのルートルールに指定できるのは、 |
urlRewrite.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: routes pathMatchers: - name: 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: routes pathMatchers: - name: 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/*
に変更されます。単一のルート内でホストの書き換えとパスの書き換えの両方を行うこともできます。
例: 変数を使用して 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: routes pathMatchers: - name: routes routeRules: - priority: 10 origin: my-origin matchRules: - prefixMatch: "/on-demand/" routeAction: 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
フィールドとrouteAction.urlRedirect
フィールドの両方を同時に設定することはできません。 - HTTPS にリダイレクトするルートでは、少なくとも 1 つの SSL 証明書がサービスに接続されている必要があります。
すべてのリクエストを HTTPS にリダイレクトする
すべてのリクエストを(HTTP ではなく)HTTPS にリダイレクトするには、すべてのクライアント リクエストが自動的に HTTPS にリダイレクトされるように各サービスを構成します。HTTP 経由で接続するクライアントには、http:// ではなく https:// を使用して、Location
ヘッダーを同じ URL に設定した 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)ポリシーを使用すると、ルートごとのポリシーに基づいて、Access-Control-Allow-Origins
などの CORS ヘッダーを自動的に設定できます。
これらのヘッダーを使用すると、メディア CD サービスへのクロスオリジン呼び出しが可能になります。これらは、ウェブサイトのフロントエンドとは異なるドメイン(オリジン)でホストされている可能性があるため、明示的に許可されないクロスオリジン リクエストが阻止されます。
CORS ポリシーは EdgeCacheService
の一部として構成され、ルートごとに設定できます。
CORS の構成
次の表で、CORS ポリシーを構成するフィールドを示します。
フィールド | 説明 | 例 |
---|---|---|
allowOrigins |
たとえば、動画コンテンツの配信先が |
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
ブラウザ クライアントが CORS プリフライト リクエストへのレスポンスをキャッシュに保存する期間を秒単位で指定する 一部のブラウザは、最大値(86400s)が指定されている場合でも、2 時間以下に制限されます。 |
Access-Control-Max-Age: 7200
|
allowMethods |
Media CDN がサポートするメソッドは、 |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
これは通常、動画プレーヤーで必要になります。プレーヤーはクロスオリジンをリクエストする際に、動画コンテンツのレスポンス ヘッダーにアクセスする必要があります。 |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
これは通常、動画プレーヤーで必要になります。プレーヤーは、コンテンツのクロスオリジンをリクエストするときに、動画コンテンツの特定のレスポンス ヘッダーにアクセスする必要がある場合があります。 |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
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"
CORS の詳細については、web.dev に関する CORS の記事をご覧ください。
ルーティングのトラブルシューティング
一部のリクエストが一致しない、またはエラーが返される場合:
- ルートには、
prefixMatch
、fullPathMatch
、pathTemplateMatch
のいずれか 1 つのみが定義されたmatchRule
が必要です。これらのフィールドのいずれかが含まれていない場合、API からエラーが返されます。 - 各ルートの
priority
が正しく設定されていることを確認してください。より範囲の狭い(長い)ルートは、より広範囲で短いルートの一致よりも優先度が高い必要があります。 GET
、HEAD
、OPTIONS
リクエストのみがサポートされています。他の HTTP メソッドは HTTP405 (Method Not Allowed)
エラーで拒否されます。- 本文付きの HTTP GET リクエストやトレーラーを含むリクエストは、HTTP
400
エラーで拒否されます。これは、GET リクエストでリクエスト本文が許可されていないためです。 - クエリ パラメータとヘッダー マッチングは論理「AND」です。リクエストがすべてのクエリ パラメータ/ヘッダーキー(および指定された場合は値)と一致する必要があります。
次のステップ
- キャッシュの構成に関するドキュメントを確認する。
- さまざまな生成元に接続する方法を理解します。
- サービスの TLS(SSL)証明書を設定します。
- コンテンツへのアクセスを認証するように署名付きリクエストを構成する。