媒体 CDN 提供高级 HTTP 路由功能,可让您以精细的级别将流量映射到特定的边缘配置和源。
配置路由规则
为媒体 CDN 服务配置路由规则。
控制台
在 Google Cloud 控制台中,前往媒体 CDN 页面。
如需打开要为其配置路线规则的服务的详情页面,请点击相应服务的名称。
如需切换到修改模式,请点击修改按钮。
如需转到路由部分,请点击下一步。
请至少指定一条主机规则。点击添加主机规则。然后, 以下:
对于主机,请至少指定一个要匹配的主机。
在说明中,为主机规则提供简要说明。
或者,如要修改主机规则,请点击箭头将其展开。
请至少指定一条路由规则。点击添加路由规则。
或者,如需修改路由规则,请点击相应行中的
Edit(修改)。在修改路由规则窗格的优先级中,将 路由优先级。
对于说明,提供简要说明有助于找到 在规则列表中选中该规则
在“匹配”部分中,至少指定一个匹配条件。点击 添加匹配条件。之后,执行以下操作:
- 对于匹配类型,选择任意路径匹配选项。
对于路径匹配,请指定名称、路径或模板。不妨考虑使用通配符模式匹配。
如果需要,还可以选中对路径值区分大小写。
可选:选择标头匹配和查询参数匹配。 然后,点击相关按钮以添加标头和查询参数。 为每个字段指定名称、匹配类型和值。
如需了解详情,请参阅按标头和查询参数进行匹配。
要保存匹配条件,请点击完成。
对于主要操作,请选择以下选项之一:
从来源提取:如需将请求定向到特定来源,请执行以下操作: 请选择此选项,然后选择一个来源
网址重定向:如需重定向请求,请选择此选项。然后,指定重定向类型、路径和状态代码。
(可选)选择将所有响应重定向到 HTTPS 或剥离查询的选项。
点击高级配置。
在 Header action 部分中,点击 Add an item。
选择操作类型,然后将标头指定为名称和值对。接着,点击完成。
在路由操作部分,点击添加一项。
指定操作类型及其相关选项。接着,点击完成。
对于 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 文件,如 部分。
如需更新该服务,请导入您的媒体 CDN 配置 提取 YAML 文件使用
gcloud edge-cache services import
命令。gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
匹配请求
媒体 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
路径匹配
媒体 CDN 支持完全匹配(完全匹配)、前缀匹配和通配符路径匹配。路径匹配可与基于主机、标头和查询参数结合使用 来构建精细的请求路由规则。
以下是针对网址路径进行匹配的三种方式。
字段 | 说明 | 示例 |
---|---|---|
matchRules[].fullPathMatch
|
fullPathMatch 条件与完整网址路径匹配,
(不包含查询字符串)。您必须指定尾部斜线(如果适用)。
|
匹配规则为
|
matchRules[].prefixMatch
|
prefixMatch 条件用于匹配网址路径前缀;以相同字符串开头的网址会匹配。
|
匹配规则为 |
matchRules[].pathTemplateMatch
|
pathTemplateMatch 条件支持
通配符,可让您匹配复杂的网址格式和路径,
和捕获用于重写网址的命名变量。
|
匹配规则为
如需查看更多示例,请参阅 模式匹配部分。 |
有关详情,请参阅
MatchRule
。
例如,如需匹配以 /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
的请求与此路由不匹配。
在第二种情况下,除非配置了其他路由或通用路由,否则媒体 CDN 会返回 HTTP 404
错误。
如需有关具有相似前缀的路由的优先级规则的指导,请参阅路由优先级和排序部分。
模式(通配符)匹配
通过格式匹配,您可以匹配网址的多个部分,包括部分网址 和后缀(文件扩展名)添加网址。
您还可以在 pathTemplateMatch
字段中将一个或多个路径组件与命名变量相关联,然后在 pathTemplateRewrite
字段中重写网址时引用这些变量。这样,您就可以先重新排序并移除网址组成部分
相应请求会发送到您的源
以下示例展示了如何匹配两个不同的网址后缀:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
支持的语法包括:
运算符 | Matches | 示例 |
---|---|---|
*
|
匹配单个路径组成部分,直到下一个路径分隔符:/
|
/videos/*/*/*.m4s 与 /videos/123414/hls/1080p5000_00001.m4s 匹配。
|
**
|
匹配零个或多个路径段。如果存在,必须为最后一个运算符。 |
/**.mpd 个匹配项
/content/123/india/dash/55/manifest.mpd 。
|
{name} or {name=*}
|
与一个路径段匹配的已命名变量。
匹配单个路径组成部分,一直到下一个路径分隔符:
|
/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=**}
|
与零个或多个路径段匹配的命名变量。 如果存在,必须为最后一个运算符。 |
|
注意:
- 如果您不想重写网址,请使用更简单的
*
和**
运算符。 - 使用变量捕获路径组成部分时,
均无法在后续调用中被引用,
pathTemplateRewrite
。有关示例,请参见 捕获路径变量部分。 - 您不能在后续
pathTemplateRewrite
中引用同一路线上的pathTemplateMatch
中不存在的变量。 - 变量区分大小写,
{FORMAT}
、{forMAT}
和{format}
代表不同的变量和值。 - 您最多可以在匹配中指定 10 个运算符(通配符或变量)。
pathTemplateMatch
和pathTemplateRewrite
字段不得超过 255 个字符。
示例:根据文件扩展名进行匹配
以下示例展示了通配符运算符的常见用例:匹配路径组件中到后缀的所有内容。
在这种情况下,您需要执行以下操作:
- 从清单来源提取以
.m3u8
和.mpd
结尾的视频清单(播放列表),并对这些响应应用较短的 TTL(5 秒),因为它们会定期更改。 - 从片段来源提取以
.ts
和.m4s
结尾的视频片段;以及 为这些响应应用较长的(1 天)TTL。
使用 SSAI(服务器端广告插播)或 DAI(动态广告插播)服务时,以及对于清单每隔几秒更新一次的直播视频时,通常会采用这种方法。
以下配置演示了如何配置媒体 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
示例:捕获路径变量
以下示例展示了如何使用命名变量来描述一个或多个 路径的组成部分。
这些变量可用于 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}
变量可捕获一个路径段。路径段是指网址路径中一对/
(“斜线”)之间的所有字符。 - 变量
{name=**}
可捕获所有剩余的路径段;在此 与segments/00001.ts
和master.m3u8
都匹配。 - 在同一路线上的
pathTemplateRewrite
中,您可以引用在pathTemplateMatch
中捕获的部分变量。您明确省略了{country}
和{lang}
变量,因为它们与源代码中的目录结构不匹配。
在此示例中,会出现以下情况:
- 传入请求网址
/us/en/hls/123139139/segment_00001.ts
与pathTemplateMatch
,重写为/123139139/hls/segment_00001.ts
。 - 传入请求网址
/us/123139139/master.m3u8
与不pathTemplateMatch
,然后收到 HTTP404 (Not Found)
响应。 - 传入请求网址
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
也与pathTemplateMatch
匹配,并会在发送到来源之前重写为/c966cbbe6ae3/dash/subtitle_00001.vtt
。
要详细了解通配符匹配如何与网址重写进行互操作,请参阅 重写部分。
主机匹配
每项服务都可以匹配多个主机名,且每组主机名包含 自己的路由组(称为“路径匹配器”)。最常见的情况是 一个服务的所有主机名都映射到一组共享路由, 主机列表和一个路径匹配器。
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[]
条目。
您还可以定义路线组(例如,按国家/地区分组或 而不是按需模式)。由于每项服务都有一项安全政策 通常建议为每个市场(地理位置)或工作负载使用一项服务 资源。
注意:
- 包含端口的主机(或 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
。
根据标题和查询参数进行匹配
您可以配置路由,以便根据特定标头和查询参数名称以及标头值的存在情况(前缀、后缀或完全匹配)进行匹配。
查询参数和标头匹配是逻辑“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"
在此示例中,网址开头包含 /videos/
且包含 x-device-name: roku
标头的请求与此路由匹配。缺少此标头名称或具有其他值的请求与此路由不匹配。
有关详情,请参阅
HeaderMatch
。
同样,要匹配查询参数,请指定一个或多个
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 规范。
定义无限别名(默认)路由
默认情况下,媒体 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: /
您可以选择在提取来源之前重写网址,也可以重定向到默认页面(例如着陆页),而不是将请求“原样”发送到来源。
路由优先级和排序
routeRules[]
数组中的每个路线都必须有一个关联的 priority
。
应该为更具体的路由设置较高的优先级(数字越小)。答
如果路由匹配前缀为 /stream/
,且优先级为 1 的路由,则会阻止
/stream/live/eu/
(优先级为 5)的更具体的路由,无法与任何路由匹配
请求。
- 优先级最高的路由为“1”,最低的路由为“999”。
- 您不能配置两条或更多具有相同优先级的 routeRule。优先级 设为 1 到 999 之间的数字(含 1 和 999)。
- 通过定义通用路由,您可以将所有不匹配的请求发送到默认来源,或将其重定向到着陆页或端点。
在以下示例中,您可以看到 /live/us/
路由永远不会
匹配,因为 /live/
路由的优先级较高:
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/
时,仍可连接到 /live/
路由,
优先级 2。
方法过滤
默认情况下,媒体 CDN 仅代理 GET
、HEAD
和 OPTIONS
方法,并过滤掉可以修改源的方法。
您可以通过指定
您想要通过代理连接到源的方法。除了GET
、HEAD
、
和 OPTIONS
,媒体 CDN 支持 PUT
、POST
、DELETE
和
PATCH
。
如需为路由规则配置对一组方法的支持,请指定一个 routeMethods
部分,其中包含每个方法的 allowed_methods
值。
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 如何在特定情况下将网址的多个表示形式合并为单个规范表示形式。
路径规范化可以通过减少表示相同内容的请求网址数量,以及减少预期使用规范化路径的源站出现的源站错误,直接提高缓存命中率。
系统会根据以下规则对传入请求进行标准化处理:
- 多个连续斜杠会合并为一个斜杠。例如,网址路径
/videos///12345/manifest.mpd
会规范化为/videos/12345/manifest.mpd
。 - 路径细分根据
RFC 3986 第 6.2.2.3 节。
例如,根据以下规则,路径
/a/b/c/./../../g
已标准化为/a/g
该 “移除点线段” RFC 3986 中定义的算法。此规范化会在检查缓存或将请求转发到源之前进行。 - 请求未对百分比编码进行标准化。例如,包含
百分号编码的斜杠字符 (
%2F
) 不会解码为未编码的 表单。
网址仍然区分大小写,不会进行大小写规范化处理。许多网址都包含区分大小写的 Base64 编码,包括包含已签名请求令牌的网址。
重写和重定向
以下部分提供了有关如何重写请求和配置重定向的示例。
重写请求网址
Media CDN 支持主机和路径重写。重写会改变 发送到源站的网址,可让您根据需要修改主机和路径。托管和 路径重写在路由级别,让您可以定义 基于任何匹配器(包括路径、查询参数和请求)被重写 标头。
有关详情,请参阅
RouteAction.UrlRewrite
。
以下是重写请求的三种方式:
字段 | 说明 |
---|---|
urlRewrite.pathPrefixRewrite
|
重写路径,移除与请求匹配的
在单个路线规则中,只能指定 |
urlRewrite.pathTemplateRewrite
|
在单个路线规则中,只能指定 |
urlRewrite.hostRewrite
|
在请求发送到源服务器之前重写主机。 |
注意:
- 重写的网址不会更改缓存键。缓存键基于客户端发送的请求网址。
- 在路由匹配和签名请求验证之后进行重写。路线 不会与其他匹配规则重新匹配。
示例:移除路径前缀
例如,如需将客户端请求网址从 /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
的工作原理是替换与
值为 pathPrefixRewrite
的 matchRules[].prefixMatch
。
如需重写主机名(例如,将 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"
在这种情况下,源请求网址将从
cdn.example.com/videos/*
至 my-bucket.s3.us-west-2.amazonaws.com/videos/*
。
您还可以在单个路由中结合使用主机重写和路径重写。
示例:使用变量重写网址
如需使用 pathTemplateMatch
和 pathTemplateRewrite
重写传入请求网址的部分内容,请参阅捕获变量部分。
重定向请求
媒体 CDN 支持三种类型的重定向:
- 主机重定向,仅重定向主机(网域),路径和查询参数保持不变。
- 路径重定向,会完全替换路径。
- 路径前缀重定向,只会替换匹配的前缀。
重定向默认设置为 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(已找到) |
SEE_OTHER |
HTTP 303(查看其他选项) |
TEMPORARY_REDIRECT |
HTTP 307(临时重定向) |
PERMANENT_REDIRECT |
HTTP 308(永久重定向) |
注意:
- 路由可以将流量定向到源站,也可以返回
客户端。您不能同时设置
origin
和urlRedirect
字段。 - 重定向到 HTTPS 的路线需要将至少一个 SSL 证书附加到服务。
如需了解详情,请参阅 RouteRule.UrlRedirect
的 API 规范。
将所有请求重定向到 HTTPS
要将所有请求重定向到 HTTPS(而不是 HTTP),您可以在
将您的服务自动将所有客户端请求重定向到 HTTPS。系统会向通过 HTTP 连接的客户端发送 HTTP 301 (Permanent Redirect)
响应,并使用“https://”而非“http://”将 Location
标头设置为同一网址。
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
您还可以选择设置 严格传输安全 标头作为响应标头,以指示客户端始终直接通过 HTTPS。
使用第三方存储后端
媒体 CDN 支持连接到可公开访问的 HTTP Google Cloud 之外的端点,包括 AWS S3 存储分区、Azure Blob Storage 和其他存储提供程序。如果您采用的是多云架构,或者尚未使用 Storage Transfer Service 将数据迁移到 Cloud Storage,这项功能会很有用。
在 AWS S3 中配置虚拟主机存储桶的最小源配置:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
如果您使用的存储桶名称与为 EdgeCacheService
资源配置的主机名不匹配,则还必须为与此源(或来源)关联的路由配置主机重写。否则,从源提取时,系统会使用由客户端请求设置的主机标头。
例如,如需将路径前缀为 /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 政策,您可以根据每个路由的政策自动设置 CORS 标头,例如 Access-Control-Allow-Origins
。
配置 CORS
媒体 CDN 允许您为
EdgeCacheService
。
CORS 政策使用一组常见的 HTTP 标头定义这些规则。您可以
在响应中设置常用的 CORS 标头,如
Access-Control-Allow-Origin
、Access-Control-Max-Age
、
和 Access-Control-Allow-Headers
。借助这些标头
跨源调用可能造成了
托管在与网站前端不同的网域(源)上,
阻止未经您明确许可的跨源请求。
例如,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
作为来源
和 X-Client-ID
标头,您可以在 CORS 请求中配置corsPolicy
具体如下:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
在 EdgeCacheService 内的 routing.pathMatchers[].routeRules[].routeAction.corsPolicy
处配置 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://stream.example.com
|
maxAge |
设置 某些浏览器会将此值限制为 2 小时或更短时间,即使指定了最大值 (86400 秒) 也是如此。 |
Access-Control-Max-Age: 7200
|
allowMethods |
设置 默认情况下,媒体 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"
排查路由问题
如果某些请求未检索到匹配结果或返回错误,请检查 以下:
- 路线必须具有
matchRule
,且只能包含prefixMatch
、 已定义fullPathMatch
或pathTemplateMatch
。如果您未添加其中一个字段,该 API 会返回错误。 - 确保正确设置每个路由的
priority
:更具体的(更长)路由应比更短、更广泛的路由匹配具有更高的优先级。 - 默认情况下,仅支持
GET
、HEAD
和OPTIONS
请求。 如需配置对其他方法的支持,请参阅路由方法。为特定路由未启用的方法将被拒绝并 HTTP405 (Method Not Allowed)
错误。 - 包含正文的 HTTP
GET
请求或包含预加载的任何请求都会被拒绝,并返回 HTTP400
错误,因为GET
请求不允许有请求正文。 - 查询参数和标头匹配采用逻辑“AND”,请求必须 匹配所有查询参数或标头键(和值,如已指定) 与指定的路线匹配。
后续步骤
- 查看有关配置缓存的文档。
- 了解如何连接到不同的来源。
- 设置 TLS (SSL) 证书 服务。
- 配置已签名请求,以对内容访问权限进行身份验证。