Media CDN proporciona capacidades avanzadas de enrutamiento HTTP que te permiten asignar tráfico a configuraciones y orígenes perimetrales específicos a nivel detallado.
Solicitudes coincidentes
Una configuración de Media CDN contiene un conjunto de rutas definidas en el
Enrutamiento
para una
EdgeCacheService
recurso.
Estas rutas coinciden con las solicitudes basadas (al menos) en un host. Para obtener más detalles sobre cómo
el tráfico se dirige a un origen, consulta
HostRule
y PathMatcher
.
Cada ruta puede definir su propia configuración de CDN, reescrituras, redireccionamientos,
Políticas de CORS, encabezados HTTP personalizados y asignación de origen.
Las rutas pueden compartir orígenes.
Por ejemplo, puede enrutar solicitudes de manifiestos a un origen y definir un TTL de caché de corta duración y un política de almacenamiento en caché negativo. Las solicitudes de segmentos se pueden dividir en otro origen mediante el uso de encabezados y parámetros de consulta para desglosar tipos de manifiestos o usuarios específicos.
En el siguiente ejemplo, se muestra cómo enrutar las solicitudes que coinciden con un encabezado específico.
parámetro de consulta y prefijo de ruta de acceso para el host 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
Coincidencia de ruta
Media CDN admite la coincidencia de rutas de acceso completa (exacta), con prefijos y comodines. La coincidencia de rutas se puede combinar con parámetros basados en host, encabezado y consulta para la creación de reglas de enrutamiento de solicitudes detalladas.
A continuación, se muestran tres formas de establecer coincidencias en una ruta de URL.
Campo | Descripción | Ejemplo |
---|---|---|
matchRules[].fullPathMatch
|
La condición fullPathMatch coincide con la ruta de URL completa, que no incluye la cadena de consulta. Debes especificar la actividad
o barras diagonales, si es relevante.
|
Una ruta con una regla de coincidencia de Un |
matchRules[].prefixMatch
|
La condición prefixMatch coincide con el prefijo de la ruta de URL. URL
que empiecen con la misma cadena de texto.
|
Una ruta con una regla de coincidencia de |
matchRules[].pathTemplateMatch
|
La condición pathTemplateMatch admite
comodines, lo que te permite hacer coincidir patrones de URL y rutas complejas
segmentos, y capturan variables con nombre para reescribir las URLs.
|
Una ruta con una regla de coincidencia de
Tanto Para ver más ejemplos, consulta el coincidencia de patrones. |
Para obtener más información, consulta las especificaciones de la API para
MatchRule
.
Por ejemplo, para que coincidan todas las solicitudes que comienzan con /stream/
, crea una regla de enrutamiento
similar a lo siguiente:
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/
En este ejemplo, se incluye explícitamente la barra final en la regla de coincidencia:
- Una solicitud a
media.example.com/stream/id/1234/hls/manifest.m3u8
coincide esta ruta. - Una solicitud a
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
no coinciden con esta ruta.
En el segundo caso, Media CDN muestra un error 404
de HTTP,
a menos que haya otra ruta o una ruta genérica
configurado.
Si deseas obtener orientación sobre el funcionamiento de la predecencia para las rutas con prefijos similares, consulta la sección de prioridad y orden de la ruta.
Coincidencia de patrón (comodín)
La coincidencia de patrones te permite hacer coincidir varias partes de una URL, incluidas las URL parciales. y sufijos (extensiones de archivo), con la sintaxis de comodines.
También puedes asociar uno o más componentes de la ruta de acceso con variables con nombre en un
pathTemplateMatch
y, luego, haz referencia a esas variables cuando reescribas la URL en
un campo pathTemplateRewrite
. Esto te permite reordenar y quitar los componentes de la URL antes
la solicitud se envía a tu origen.
En el siguiente ejemplo, se muestra cómo puedes establecer coincidencias con dos sufijos de URL diferentes:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
La sintaxis compatible incluye lo siguiente:
Operador | Coinciden | Ejemplo |
---|---|---|
*
|
Coincide con un solo componente de ruta, hasta el siguiente separador de ruta: / .
|
/videos/*/*/*.m4s coincide con
/videos/123414/hls/1080p5000_00001.m4s .
|
**
|
Coincide con cero o más segmentos de ruta de acceso. Si está presente, debe ser el último operador. |
/**.mpd coincide con
/content/123/india/dash/55/manifest.mpd .
|
{name} or {name=*}
|
Una variable con nombre que coincide con un segmento de ruta de acceso.
Coincide con un solo componente de ruta, hasta el siguiente separador de ruta:
|
/content/{format}/{lang}/{id}/{file}.vtt coincidencias
/content/hls/en-us/12345/en_193913.vtt y capturas
format="hls" , lang="en-us" y id="12345"
y file="en_193913" como variables.
|
{name=videos/*}
|
Una variable con nombre que coincide con más de un segmento de ruta de acceso. El componente de la ruta
que coinciden con videos/* como la variable con nombre.
|
/videos/{language=lang/*}/* coincidencias
/videos/lang/en/video.m4s y propaga la variable de ruta de acceso
language con el valor lang/en .
|
{name=**}
|
Una variable con nombre que coincide con cero o más segmentos de ruta de acceso. Si está presente, debe ser el último operador. |
|
Notas:
- Si no vas a reescribir una URL, usa los operadores
*
y**
más simples. - Al usar variables para capturar componentes de la ruta, cualquier parte de la URL que
no sean capturados por una variable, no se podrá hacer referencia a ellos en una
pathTemplateRewrite
. Para ver un ejemplo, consulta el sección sobre la captura de variables de ruta de acceso. - No puedes hacer referencia a variables en un
pathTemplateRewrite
posterior que no están en elpathTemplateMatch
de la misma ruta. - Las variables distinguen mayúsculas de minúsculas, con
{FORMAT}
,{forMAT}
y{format}
. que representan diferentes variables y valores. - Puedes especificar hasta 10 operadores (comodines o variables) en una coincidencia.
Los campos
pathTemplateMatch
ypathTemplateRewrite
no deben exceder los 255 caracteres.
Ejemplo: coincidencia en una extensión de archivo
En el siguiente ejemplo, se muestra un caso de uso común para los operadores de comodín: coincidencias todos los componentes de la ruta de acceso hasta un sufijo.
En este caso, haz lo siguiente:
- Obtén los manifiestos de video (listas de reproducción) que terminan en
.m3u8
y.mpd
desde el de manifiesto, aplicar un TTL corto (de 5 segundos) a estas respuestas porque cambian con regularidad. - Recuperar los segmentos de video que terminan en
.ts
y.m4s
a partir del origen del segmento aplica un TTL más largo (1 día) a estas respuestas.
Este enfoque a menudo se usa cuando se usan servicios SSAI (inserción de anuncios del servidor) o DAI (inserción de anuncios dinámicos) y videos en vivo en los que el manifiesto se actualiza cada pocos segundos.
La siguiente configuración muestra cómo establecer tu Enrutamiento de Media CDN para admitir esto:
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
Ejemplo: captura de variables de ruta
En el siguiente ejemplo, se muestra cómo usar variables con nombre para describir uno o más de la ruta de acceso.
Estas variables se pueden usar en un pathTemplateRewrite
para reescribir la ruta de acceso anterior.
a la solicitud que se envía al origen o para hacer una
pathTemplateMatch
se describe a sí mismo.
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}"
En particular, haz lo siguiente:
- Cada variable
{name}
captura un solo segmento de ruta de acceso. Un segmento de ruta son todos los caracteres entre un par de/
(“diagonal”) en una ruta de URL. - Una variable de
{name=**}
captura todos los segmentos de ruta restantes. en esta caso, coincide consegments/00001.ts
y conmaster.m3u8
. - En el
pathTemplateRewrite
de la misma ruta, puedes hacer referencia a algunos de las variables que capturaste enpathTemplateMatch
. Usted explícitamente omiten las variables{country}
y{lang}
porque no coinciden con de directorio en el origen.
Con este ejemplo, ocurre lo siguiente:
- Una URL de solicitud entrante de
/us/en/hls/123139139/segment_00001.ts
coincide elpathTemplateMatch
y se reescribe en/123139139/hls/segment_00001.ts
antes de que se envíe al origen. - Una URL de solicitud entrante de
/us/123139139/master.m3u8
no coincide conpathTemplateMatch
y recibe una respuesta HTTP404 (Not Found)
. - Una URL de solicitud entrante de
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
también coincide conpathTemplateMatch
y se reescribe en/c966cbbe6ae3/dash/subtitle_00001.vtt
antes de que se envíe al origen.
Para obtener más información sobre cómo funciona la coincidencia de comodines con la reescritura de URL, consulta la sección rewrites.
Coincidencia de host
Cada servicio puede coincidir con varios nombres de host, y cada conjunto de nombres de host contiene su propio grupo de rutas (conocidas como comparadores de rutas de acceso). En el caso más común, todos los nombres de host de un servicio se asignan a un único conjunto de rutas compartidas con un único de hosts y un único comparador de rutas de acceso.
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
A los hosts que no coinciden se les entrega una página HTTP 404
predeterminada. Para aceptar cualquier host,
puedes incluir el carácter comodín *
como una entrada hostRules[].hosts[]
.
También puedes definir grupos de rutas (por ejemplo, agrupar por país o tiempo real) y a pedido). Como cada servicio tiene una sola política de seguridad, generalmente recomiendan tener un servicio para cada mercado (ubicación geográfica) o carga de trabajo. que tienes.
Notas:
- Los encabezados de host (o HTTP/2
:authority
) que contienen un puerto se para compararlo con un host configurado. No necesitas especificar explícitamente ports. - Si la solicitud es a través de HTTP, una entrada
hostRules[].hosts[]
de*.vod.example.com
coincide conus.vod.example.com
yus.vod.example.com:80
- Si la solicitud es a través de HTTPS (TLS), una entrada
hostRules[].hosts[]
de*.vod.example.com
coincide conus.vod.example.com:443
.
Para obtener más información, consulta las especificaciones de la API para
HostRule
.
Coincidencia en encabezados y parámetros de consulta
Puedes configurar las rutas para que coincidan con encabezados y nombres de parámetros de consulta específicos. así como la presencia de un valor de encabezado (prefijo, sufijo o concordancia exacta).
La coincidencia del parámetro de consulta y del encabezado es lógica "AND": la solicitud debe coincidir. todos los parámetros de consulta y las claves de encabezado (y los valores, si se especifican) para que coincidan la ruta dada.
Por ejemplo, si quieres enrutar solicitudes con un nombre de campo de encabezado específico y
valor de encabezado a un origen llamado alternate-origin
, configura tu coincidencia
condiciones en 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"
En este ejemplo, las solicitudes con /videos/
al comienzo de la URL y el
El encabezado x-device-name: roku
coincide con esta ruta. Solicitudes sin este encabezado
o con un valor diferente no coinciden con esta ruta.
Para obtener más información, consulta las especificaciones de la API para
HeaderMatch
.
Del mismo modo, para que coincidan con los parámetros de consulta, especifica uno o más
queryParameterMatches
de la siguiente manera:
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"
En este ejemplo, una solicitud del cliente de
https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
coincide con esta ruta.
Para obtener más información, consulta las especificaciones de la API para
QueryParameterMatcher
.
Define una ruta genérica (predeterminada)
De forma predeterminada, Media CDN muestra un error HTTP 404 (Not Found)
si se realiza una solicitud.
no coincide con ninguna ruta configurada.
Para configurar una ruta general, para un pathMatcher
determinado (colección de
rutas), haz lo siguiente:
- Crea un
routeRule
con la prioridad más baja (número más alto), por ejemplo, 999, que es la menor prioridad de ruta posible. - Configura un
matchRule
con una coincidencia de prefijo de/
(coincide con todas las solicitudes) rutas de acceso). - Configura (uno de) un
origin
ourlRedirect
en la ruta.
Por ejemplo, para configurar una ruta genérica que dirija todas las solicitudes no coincidentes
a un origen predeterminado llamado my-origin
, crea una nueva ruta con priority: 999
y un matchRules[].prefixMatch
de /
de la siguiente manera:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
Opcionalmente, puedes reescribir la URL antes de la recuperación de origen o redireccionar a una página predeterminada (como su página de destino) en lugar de enviar la solicitud "tal cual" al origen.
Orden y prioridad de ruta
Cada ruta en un array de routeRules[]
debe tener un priority
asociado con
que la modifica.
Las rutas más específicas se deben establecer con una prioridad más alta (cantidad menor). R
que coincida con un prefijo de /stream/
con una prioridad de 1; de lo contrario, se evita un
ruta más específica de /stream/live/eu/
con una prioridad de 5 respecto de cualquier
solicitudes.
- La ruta de mayor prioridad es "1" y la más baja es "999".
- No puedes configurar dos o más routeRules con la misma prioridad. Prioridad para cada regla debe establecerse en un número entre 1 y 999, inclusive.
- Definir una ruta genérica te permite enviar todas solicitudes que no coinciden a un origen o redireccionamiento predeterminado a una página de destino o extremo.
En el siguiente ejemplo, puedes ver que la ruta /live/us/
nunca se
coincide porque la ruta /live/
tiene una prioridad más alta:
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: /
Para solucionar esto, coloca la ruta más específica (más larga) en una prioridad más alta:
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: /
Esto permite que la ruta más específica coincida con las solicitudes de forma correcta. Una solicitud
con el prefijo /live/eu/
seguiría cayendo a la ruta /live/
en
prioridad 2.
Filtrado de métodos
De forma predeterminada, Media CDN solo procesa GET
, HEAD
y OPTIONS
.
métodos a tu origen y filtra los métodos que pueden modificar tu origen.
En Vista previa, puedes anular este valor predeterminado.
para una regla de enrutamiento específica, especificando los métodos que
como proxy a tu origen. Además de GET
, HEAD
y OPTIONS
,
Media CDN admite PUT
, POST
, DELETE
y PATCH
.
Para configurar la compatibilidad con un conjunto de métodos para una regla de enrutamiento, especifica una
Sección routeMethods
que tiene un valor allowed_methods
para cada método.
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
En la vista previa, Media CDN permite actualizar y visualizar esto.
configuración con la API de servicios de red v1alpha1
Como alternativa, puedes usar el comando gcloud alpha edge-cache services export
y el comando gcloud alpha edge-cache services import
para actualizar los archivos YAML de configuración del servicio.
Normalización de ruta de acceso
La normalización de la ruta de acceso describe cómo Media CDN combina múltiples de una URL en una única representación canónica bajo requisitos reales.
La normalización de la ruta de acceso puede mejorar directamente las tasas de acierto de caché mediante la reducción del número de URLs de solicitudes que representan el mismo contenido y mitigando los errores de origen para orígenes que esperan rutas normalizadas.
Las solicitudes entrantes se normalizan de acuerdo con lo siguiente:
- Varias barras consecutivas se combinan en una sola. Por ejemplo, un
La ruta de URL de
/videos///12345/manifest.mpd
se normaliza a/videos/12345/manifest.mpd
- Los segmentos de ruta se normalizan de acuerdo con
Sección 6.2.2.3 de RFC 3986.
Por ejemplo, la ruta
/a/b/c/./../../g
se normaliza en/a/g
según el “quita segmentos de puntos” definido en RFC 3986. Esta normalización ocurre antes de verificar a la caché o reenviar la solicitud al origen. - Las solicitudes no están normalizadas de codificación porcentual. Por ejemplo, una URL con una URL
el carácter de barra con codificación por ciento (
%2F
) no se decodifica en el campo formulario.
Las URLs distinguen mayúsculas de minúsculas, y no están normalizadas. Muchas URL contienen codificaciones de base64 que distinguen entre mayúsculas y minúsculas, incluidas las URLs con tokens de solicitud firmada.
Reescrituras y redireccionamientos
En las siguientes secciones, se proporcionan ejemplos sobre cómo reescribir solicitudes y configurar o redireccionamientos.
Reescribe las URLs de solicitud
Media CDN admite reescrituras de host y de ruta de acceso. Las reescrituras cambian URL enviada al origen y te permite modificar los hosts y las rutas de acceso según sea necesario. Alojar y se realizan a nivel de la ruta, lo que te permite definir qué solicitudes se reescriben en función de cualquier comparador, incluidos la ruta de acceso, el parámetro de consulta y la solicitud. encabezado.
Para obtener más información, consulta las especificaciones de la API para
RouteAction.UrlRewrite
.
A continuación, se muestran tres formas de reescribir una solicitud:
Campo | Descripción |
---|---|
urlRewrite.pathPrefixRewrite
|
Reescribe la ruta de acceso y quita el prefijo especificado en el
Solo una de las siguientes opciones: |
urlRewrite.pathTemplateRewrite
|
Solo una de las siguientes opciones: |
urlRewrite.hostRewrite
|
Vuelve a escribir el host antes de que la solicitud se envíe al servidor de origen. |
Notas:
- Las URLs reescritas no cambian la clave de caché. La clave de caché se basa en lo siguiente: la URL de la solicitud que envió el cliente.
- La reescritura ocurre después de la coincidencia de ruta y la validación de la solicitud firmada. Rutas no vuelven a coincidir con otra regla de coincidencia.
Ejemplo: quita un prefijo de ruta de acceso
Por ejemplo, para reescribir una URL de solicitud de cliente de /vod/videos/hls/1234/abc.ts
a
/videos/hls/1234/abc.ts
(quitando /vod
de la ruta de acceso), puedes usar el
Función 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/"
Un pathPrefixRewrite
funciona reemplazando todo el componente de la ruta de acceso que coincide con
el matchRules[].prefixMatch
con el valor de pathPrefixRewrite
.
Para volver a escribir un nombre de host (por ejemplo, reescribir cdn.example.com
en
my-bucket.s3.us-west-2.amazonaws.com
), puedes configurar lo siguiente:
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"
En este caso, la URL de la solicitud de origen cambiaría de
De cdn.example.com/videos/*
a my-bucket.s3.us-west-2.amazonaws.com/videos/*
.
También puedes combinar reescrituras de host y de ruta de acceso en una sola ruta.
Ejemplo: usa variables para reescribir URLs
Si deseas usar pathTemplateMatch
y pathTemplateRewrite
para reescribir partes de un
URL de solicitud entrante, consulta la documentación sobre cómo capturar variables
sección.
Solicitudes de redireccionamiento
Media CDN admite tres tipos de redireccionamientos:
- Redireccionamientos de host, que redireccionan solo al host (dominio), manteniendo la ruta de acceso y parámetros de consulta sin cambios.
- Redireccionamientos de ruta de acceso, que reemplazan la ruta por completo.
- Redireccionamientos de prefijo de ruta de acceso, que solo reemplazan el prefijo coincidente.
Los redireccionamientos se establecen de forma predeterminada en HTTP 301 (Moved Permanently)
, pero se pueden configurar para
devolver códigos de estado de redireccionamiento diferentes por ruta.
La siguiente configuración es un ejemplo de un redireccionamiento basado en prefijos:
en la que redireccionas a los usuarios que visitan https://cdn.example.com/on-demand/*
a
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
Este ejemplo también cambia el redireccionamiento a un redireccionamiento temporal que evita clientes (como navegadores) para que no lo almacenen en caché. Esto puede ser útil si esperas cambiarla próximamente.
Los valores redirectResponseCode
admitidos se muestran en la siguiente tabla.
Código de respuesta de redireccionamiento | Código de estado HTTP |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301 (Movido permanentemente) |
FOUND |
HTTP 302 (encontrado) |
SEE_OTHER |
HTTP 303 (Ver otro) |
TEMPORARY_REDIRECT |
HTTP 307 (redireccionamiento temporal) |
PERMANENT_REDIRECT |
HTTP 308 (redireccionamiento permanente) |
Notas:
- Una ruta puede dirigir el tráfico a un origen o devolver un redireccionamiento a la
cliente. No puedes configurar
origin
yurlRedirect
al mismo tiempo campos al mismo tiempo. - Las rutas que se redireccionan a HTTPS requieren que al menos un El certificado SSL se adjunta al servicio.
Para obtener más información, consulta las especificaciones de la API para
RouteRule.UrlRedirect
.
Redireccionar todas las solicitudes a HTTPS
Para redireccionar todas las solicitudes a HTTPS (en lugar de HTTP), puedes configurar cada
tus servicios para redireccionar automáticamente todas las solicitudes de clientes a HTTPS. Clientes
que se conectan a través de HTTP reciben una respuesta HTTP 301 (Permanent Redirect)
con el
El encabezado Location
se estableció en la misma URL mediante "https://" en lugar de “http://”.
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
El comando muestra una descripción de tu servicio, con requireTls
ahora configurado.
a true
.
name: MY_SERVICE requireTls: true
También puedes establecer la Seguridad de transporte estricta como un encabezado de respuesta para indicar a los clientes que siempre se conecten directamente a través de HTTPS
Usa backends de almacenamiento de terceros
La CDN de medios admite la conexión a extremos HTTP accesibles de forma pública fuera de Google Cloud, incluidos los buckets de almacenamiento de AWS S3, Azure Blob Storage y otros proveedores de almacenamiento. Esto puede ser útil si tienes un arquitectura de múltiples nubes o que aún no migraron datos a Cloud Storage Usa el Servicio de transferencia de almacenamiento.
Una configuración de origen mínima que configura un bucket alojado virtualmente en AWS S3:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
Si no usas un nombre de bucket que coincida con los nombres de host configurados para tu
EdgeCacheService
, también debes configurar una reescritura de host para las rutas
asociados con este origen (o orígenes). De lo contrario, el encabezado del Host establecido por el
cliente se usa cuando se recupera desde el origen.
Por ejemplo, para asignar todas las solicitudes con un prefijo de ruta de acceso de /legacy/
a tu
bucket externo, puedes configurar un hostRewrite
y un
pathPrefixRewrite
para quitar este prefijo de la solicitud de origen:
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
Para obtener más información sobre cómo se configura el encabezado del host en las solicitudes de origen, consulta los encabezados de la solicitud de origen en la documentación de Google Cloud.
Uso compartido de recursos entre dominios (CORS)
Uso compartido de recursos entre dominios
(CORS) es un enfoque centrado en el navegador para realizar solicitudes de origen cruzado de forma segura.
Las políticas de CORS te permiten establecer automáticamente los encabezados de CORS, como
Access-Control-Allow-Origins
, según una política por ruta.
Configurar CORS
Media CDN te permite definir una política de CORS en una ruta para un
EdgeCacheService
.
Una política de CORS define estas reglas con un conjunto común de encabezados HTTP. Puedes
establece encabezados de CORS comunes en las respuestas, como
Access-Control-Allow-Origin
, Access-Control-Max-Age
,
y Access-Control-Allow-Headers
. Estos encabezados te permiten hacer
llamadas entre dominios a los servicios de Media CDN que podrían
alojado en un dominio (origen) diferente del frontend de tu sitio web y podría
evitar las solicitudes multiorigen que no permite explícitamente.
Por ejemplo, player.example.com
y api.example.com
son orígenes diferentes
(en el sentido del navegador), y es posible que quieras tener tu aplicación de frontend
realiza solicitudes a api.example.com
para recuperar la siguiente playlist o actualiza una
de contenido relacionado. De manera similar, es posible que player.example.com
necesite
Comunícate con cdn.example.com
para recuperar playlists y segmentos de videos:
cdn.example.com
debe indicar que está bien y que
player.example.com
es allowed origin
, así como cualquier otra regla.
(encabezados permitidos, si se pueden incluir cookies).
Para dar otro ejemplo, si quieres permitir stream.example.com
como origen,
y un encabezado X-Client-ID
en las solicitudes de CORS, puedes configurar un corsPolicy
en un
ruta, de la siguiente manera:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Se configura un corsPolicy
en
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
en una
EdgeCacheService. Cada routeRule
puede definir un corsPolicy
diferente, como
necesario o ninguno en absoluto.
Si defines un valor corsPolicy
y, además, configuras un encabezado de respuesta personalizado,
Si usas los campos responseHeadersToAdd
de una ruta con el mismo nombre,
el encabezado de respuesta personalizado tiene prioridad sobre el encabezado
Valor corsPolicy
.
Si la respuesta de origen establece encabezados HTTP y tienes un valor corsPolicy
establecido, se usarán los valores de corsPolicy
en su lugar. Los valores no se contraen.
o combinarse para evitar el envío de valores de encabezado no válidos a un cliente
establecer involuntariamente una política más permisiva de la prevista.
El {origin_request_header}
especial se propaga con el encabezado HTTP Origin
.
en la solicitud del cliente. Esto se puede establecer como un valor de encabezado de respuesta personalizado en un
para el encabezado Access-Control-Allow-Origin
.
Para obtener más información, consulta la API
especificación para
RouteAction.CORSPolicy
.
Campos de política de CORS
En la siguiente tabla, se describen los campos que contiene una política de CORS.
Campo | Descripción | Ejemplo |
---|---|---|
allowOrigins |
Establece el encabezado de respuesta
Por ejemplo, si tu contenido de video se publica desde
|
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Establece el encabezado de respuesta Algunos navegadores limitan este tiempo a 2 horas o menos, incluso si se especifica el valor máximo (86,400s). |
Access-Control-Max-Age: 7200
|
allowMethods |
Establece el encabezado de respuesta De forma predeterminada, Media CDN solo admite |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
Establece el encabezado A menudo, esto es necesario para los reproductores de video, que necesitan acceder a algunos encabezados de respuesta para el contenido de video cuando lo solicitan entre dominios. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
Establece el encabezado de respuesta A menudo, esto es necesario para los reproductores de video, que podrían necesitar acceder a encabezados de respuesta específicos para el contenido de video cuando solicitan contenido entre dominios. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
Establece el encabezado de respuesta Este encabezado se omite cuando se establece como falso. |
Access-Control-Allow-Credentials: true
|
disabled |
Inhabilita el corsPolicy sin quitarlo. Antes del vuelo
Las solicitudes OPTIONS se envían mediante proxy al origen.
|
N/A |
Ejemplo de corsPolicy
En el siguiente ejemplo de configuración, se muestra una configuración básica de 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"
Cómo solucionar problemas relacionados con el enrutamiento
Si algunas solicitudes no recuperan resultados coincidentes ni muestran errores, revisa la lo siguiente:
- Una ruta debe tener un
matchRule
con exactamente uno deprefixMatch
, Se definenfullPathMatch
opathTemplateMatch
. La API devuelve un error si no incluyas uno de esos campos. - Asegúrate de que el
priority
de cada ruta esté configurado correctamente: más específico. Las rutas (más largas) deben tener una prioridad más alta sobre las rutas más cortas o anchas de rutas. - De forma predeterminada, solo se admiten solicitudes
GET
,HEAD
yOPTIONS
. En Vista previa, para configurar la compatibilidad con otros métodos, consulta Métodos de ruta. Los métodos que no están habilitados para una ruta en particular se rechazan con un error HTTP405 (Method Not Allowed)
- Se rechazan las solicitudes
GET
HTTP con un cuerpo o cualquier solicitud con avances. con un error HTTP400
, ya que los cuerpos de las solicitudes no están permitidos enGET
solicitudes. - La coincidencia del parámetro de consulta y del encabezado es lógica "AND"; la solicitud debe hacer coincidir todos los parámetros de consulta o las claves de encabezado (y los valores, si se especifican) para que coincida con la ruta dada.
¿Qué sigue?
- Revisa la documentación sobre cómo configurar el almacenamiento en caché.
- Obtén información para conectarte a diferentes orígenes.
- Configura certificados TLS (SSL) para tu servicio.
- Configurar las solicitudes firmadas para autenticar acceso al contenido.