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.
Configura una regla de ruta
Configura una regla de enrutamiento para un servicio de Media CDN.
Console
En la consola de Google Cloud, ve a la página Media CDN.
Para abrir la página Detalles del servicio para el que deseas configurar una regla de ruta, haz clic en el nombre del servicio.
Para cambiar al modo de edición, haz clic en el botón Editar.
Para navegar a la sección Enrutamiento, haz clic en Siguiente.
Especifica al menos una regla de host. Haz clic en Agregar regla de host. Luego, haz lo siguiente:
En Hosts, especifica al menos un host para la coincidencia.
En Descripción, proporciona una descripción breve de la regla de host.
Como alternativa, para editar una regla de host, haz clic en la flecha para expandirla.
Especifica al menos una regla de ruta. Haz clic en Add route rule.
Como alternativa, para editar una regla de ruta, haz clic en Editar en la fila correspondiente.
En el panel Editar regla de enrutamiento, en Prioridad, establece un valor para la prioridad de ruta.
En Descripción, proporciona una descripción breve que pueda ayudar a identificar la regla en una lista de reglas.
En la sección Coincidencia, especifica al menos una condición de coincidencia. Haz clic en Agregar una condición de coincidencia. A continuación, sigue estos pasos:
- En Tipo de concordancia, selecciona cualquier opción de coincidencia de ruta.
Para Coincidencia de ruta, especifica los nombres, las rutas de acceso o las plantillas. Considera usar la coincidencia de patrones con comodines.
Si es necesario, selecciona también Habilitar la distinción entre mayúsculas y minúsculas para el valor de la ruta de acceso.
Opcional: Selecciona Coincidencia de encabezados y Coincidencia de parámetros de consulta. Luego, haz clic en los botones relevantes para agregar encabezados y parámetros de consulta. Para cada uno, especifica el nombre, el tipo de concordancia y el valor.
Para obtener más información, consulta Coincidencia en encabezados y parámetros de consulta.
Para guardar la condición de coincidencia, haz clic en Listo.
En Acción principal, selecciona una de las siguientes opciones:
Recuperar desde un origen: Para dirigir las solicitudes a un origen específico, selecciona esta opción y, luego, selecciona un origen.
Redireccionamiento de URL: Selecciona esta opción para redireccionar las solicitudes. Luego, especifica el tipo de redireccionamiento, la ruta de acceso y el código de estado.
De forma opcional, selecciona las opciones para redireccionar todas las respuestas a HTTPS o para quitar la consulta.
Haz clic en Configuración avanzada.
En la sección Header action, haz clic en Agregar un elemento.
Selecciona un tipo de acción y, luego, especifica un encabezado como un par de nombre y valor. Luego, haz clic en Listo.
En la sección Route action, haz clic en Add an item.
Especifica un tipo de acción y sus opciones relacionadas. Luego, haz clic en Listo.
En Filtrado de métodos HTTP, selecciona Personalizar el filtrado de métodos HTTP.
Luego, selecciona los métodos HTTP que deseas que se usen como proxy para tu origen.
Para guardar la regla de ruta, haz clic en Guardar.
Para guardar los cambios en el servicio, haz clic en Actualizar servicio.
gcloud y YAML
Exporta la configuración de la CDN de Media a un archivo YAML. Usa el comando
gcloud edge-cache services export.gcloud edge-cache services export SERVICE_NAME \ --destination=FILENAME.yamlReemplaza lo siguiente:
SERVICE_NAME: el nombre de tu servicio.FILENAME: Es el nombre de tu archivo YAML.
Actualiza el archivo YAML con la configuración requerida, como se describe en las secciones de esta página.
Para actualizar el servicio, importa tu configuración de la CDN de Media desde el archivo YAML. Usa el comando
gcloud edge-cache services import.gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
Solicitudes coincidentes
Una configuración de Media CDN contiene un conjunto de rutas definidas en la sección Enrutamiento para un recurso EdgeCacheService.
Estas rutas coinciden con las solicitudes en función de (al menos) un host. Para obtener más detalles sobre cómo se dirige el tráfico 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, puedes enrutar las solicitudes de manifiestos a un origen específico y definir un TTL de caché de corta duración y una política de almacenamiento en caché negativo. Las solicitudes de segmentos se pueden dividir en otro origen con encabezados y parámetros de consulta para separar tipos de manifiesto o usuarios específicos.
En el siguiente ejemplo, se muestra cómo enrutar solicitudes que coincidan con un encabezado, un parámetro de consulta y un prefijo de ruta específicos 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 completas (exactas), de prefijos y de comodines. La coincidencia de rutas de acceso se puede combinar con la coincidencia basada en el host, el encabezado y el parámetro de consulta para crear reglas de enrutamiento de solicitudes detalladas.
A continuación, se muestran tres formas de hacer coincidir 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 barras diagonales finales, si corresponde.
|
Una ruta con una regla de coincidencia de Un |
matchRules[].prefixMatch
|
La condición prefixMatch coincide con el prefijo de la ruta de URL, las URLs que empiezan por la misma cadena coinciden.
|
Una ruta con una regla de coincidencia de |
matchRules[].pathTemplateMatch
|
La condición pathTemplateMatch admite operadores comodín, lo que te permite hacer coincidir patrones de URL y segmentos de ruta complejos, así como capturar variables con nombre para reescribir URLs.
|
Una ruta con una regla de coincidencia de Tanto Para ver más ejemplos, consulta la sección Coincidencia de patrones. |
Para obtener más detalles, consulta la especificación de la API de MatchRule.
Por ejemplo, para hacer coincidir todas las solicitudes que comienzan con /stream/, crea una regla de ruta similar a la 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.m3u8coincide con esta ruta. - Una solicitud a
media.example.com/stream-eu/id/4567/hls/manifest.m3u8no coincide con esta ruta.
En el segundo caso, Media CDN muestra un error HTTP 404, a menos que haya otra ruta o una ruta de captura configurada.
Para obtener orientación sobre cómo funciona la precedencia para las rutas con prefijos similares, consulta la sección Orden y prioridad de ruta.
Coincidencia de patrón (comodín)
La coincidencia de patrones te permite generar coincidencias con varias partes de una URL, incluidas las URLs y los sufijos parciales (extensiones de archivo), mediante una sintaxis de comodines.
También puedes asociar uno o más segmentos de ruta de acceso con variables con nombre en un campo pathTemplateMatch y, luego, hacer referencia a esas variables cuando reescribes la URL en un campo pathTemplateRewrite. Esto te permite reordenar y quitar segmentos de URL antes de enviar la solicitud a tu origen.
En el siguiente ejemplo, se muestra cómo puedes hacer coincidir 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 admitida incluye lo siguiente:
| Operador | Coinciden | Ejemplo |
|---|---|---|
*
|
Coincide con un solo segmento 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. 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 segmento de ruta, hasta el siguiente separador de ruta: |
/content/{format}/{lang}/{id}/{file}.vtt coincide con /content/hls/en-us/12345/en_193913.vtt y captura format="hls", lang="en-us", 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 segmento de ruta de acceso que coincide con videos/* se captura como la variable con nombre.
|
/videos/{language=lang/*}/* coincide con /videos/lang/en/video.m4s y completa 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. - Cuando se usan variables para capturar segmentos de ruta de acceso, no se puede hacer referencia a ninguna parte de la URL que no capture una variable en un
pathTemplateRewriteposterior. Para ver un ejemplo, consulta la sección Captura de variables de ruta. - No puedes hacer referencia a variables en un
pathTemplateRewriteposterior que no existan en elpathTemplateMatchde la misma ruta. - Las variables distinguen mayúsculas de minúsculas, y
{FORMAT},{forMAT}y{format}representan diferentes variables y valores. - Puedes especificar hasta 10 operadores (como comodines o variables) en una concordancia.
Los campos
pathTemplateMatchypathTemplateRewriteno deben superar los 255 caracteres.
Ejemplo: coincidencia en una extensión de archivo
En el siguiente ejemplo, se muestra un caso de uso común para operadores de comodín: hacer coincidir todos los segmentos de ruta hasta un sufijo.
En este caso, haz lo siguiente:
- Recupera manifiestos de video (playlists) que terminan en
.m3u8y.mpddel origen del manifiesto y aplica un TTL corto (5 segundos) a estas respuestas porque cambian con frecuencia. - Recupera los segmentos de video que terminan en
.tsy.m4sdel origen del segmento y 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.
En la siguiente configuración, se muestra cómo configurar el 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 segmentos de ruta.
Estas variables se pueden usar en un pathTemplateRewrite para reescribir la ruta de acceso antes de que se envíe la solicitud al origen o para hacer que un pathTemplateMatch complejo se autodescriba.
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 este caso, coincide consegments/00001.tsymaster.m3u8. - En el
pathTemplateRewriteen la misma ruta, puedes hacer referencia a algunas de las variables que capturaste en elpathTemplateMatch. Omites de forma explícita las variables{country}y{lang}porque no coinciden con la estructura de directorios del origen.
Con este ejemplo, ocurre lo siguiente:
- Una URL de solicitud entrante de
/us/en/hls/123139139/segment_00001.tscoincide conpathTemplateMatchy se reescribe a/123139139/hls/segment_00001.tsantes de enviarse al origen. - Una URL de solicitud entrante de
/us/123139139/master.m3u8no coincide conpathTemplateMatchy recibe una respuesta HTTP404 (Not Found). - Una URL de solicitud entrante de
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtttambién coincide conpathTemplateMatchy se vuelve a escribir en/c966cbbe6ae3/dash/subtitle_00001.vttantes de enviarse al origen.
Para obtener más información sobre cómo la coincidencia de comodines interopera con la reescritura de URLs, consulta la sección Reescrituras.
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 (conocidos como comparadores de rutas). En el caso más común, todos los nombres de host de un servicio se asignan a un solo conjunto de rutas compartidas con una sola lista de hosts y un solo comparador de rutas.
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 por contenido en vivo o on demand). Debido a que cada servicio tiene una sola política de seguridad, por lo general, recomendamos tener un servicio para cada mercado (geografía) o carga de trabajo que tengas.
Notas:
- Los encabezados de host (o
:authorityde HTTP/2) que contienen un puerto se comparan de forma implícita con un host configurado. No es necesario que especifiques los puertos de forma explícita. - Si la solicitud es a través de HTTP, una entrada
hostRules[].hosts[]de*.vod.example.comcoincide conus.vod.example.comyus.vod.example.com:80. - Si la solicitud se realiza a través de HTTPS (TLS), una entrada
hostRules[].hosts[]de*.vod.example.comcoincide conus.vod.example.com:443.
Para obtener más detalles, consulta la especificación de la API de HostRule.
Coincidencia en encabezados y parámetros de consulta
Puedes configurar rutas para que coincidan con nombres específicos de encabezados y parámetros de consulta, así como la presencia de un valor de encabezado (prefijo, sufijo o coincidencia exacta).
La coincidencia de parámetros de consulta y encabezados es un “Y” lógico: la solicitud debe coincidir con todos los parámetros de consulta y claves de encabezado (y valores, si se especifican) para coincidir con la ruta determinada.
Por ejemplo, si deseas enrutar solicitudes con un nombre de campo de encabezado y un valor de encabezado específicos a un origen llamado alternate-origin, configura tus condiciones de coincidencia 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
encabezado x-device-name: roku coinciden con esta ruta. Las solicitudes que no tienen este nombre de encabezado o que tienen un valor diferente no coinciden con esta ruta.
Para obtener más detalles, consulta la especificación de la API de HeaderMatch.
De manera similar, para hacer coincidir 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 detalles, consulta la especificación de la API de QueryParameterMatcher.
Define una ruta de captura (predeterminada)
De forma predeterminada, Media CDN muestra un error HTTP 404 (Not Found) si una solicitud
no coincide con ninguna de las rutas configuradas.
Para configurar una ruta catch-all para un pathMatcher determinado (colección de rutas), haz lo siguiente:
- Crea un
routeRulecon la prioridad más baja (número más alto), por ejemplo, 999, que es la prioridad de ruta más baja posible. - Configura un
matchRulecon una coincidencia de prefijo de/(coincide con todas las rutas de acceso de la solicitud). - Configura (uno de) un
originourlRedirecten la ruta.
Por ejemplo, para configurar una ruta de captura general que dirija todas las solicitudes que no coincidan a un origen predeterminado llamado my-origin, crea una ruta nueva 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: /
De manera opcional, puedes reescribir la URL antes de la recuperación del origen o redireccionar a una página predeterminada (como tu página de destino) en lugar de enviar la solicitud “tal como está” al origen.
Orden y prioridad de ruta
Cada ruta en un array de routeRules[] debe tener un priority asociado.
Las rutas más específicas deben establecerse en una prioridad más alta (número más bajo). De lo contrario, una ruta que coincida con un prefijo de /stream/ con una prioridad de 1 evita que una ruta más específica de /stream/live/eu/ con una prioridad de 5 coincida con ninguna solicitud.
- La ruta de prioridad más alta es “1” y la más baja es “999”.
- No puedes configurar dos o más routeRules con la misma prioridad. La prioridad para cada regla debe establecerse en un número entre 1 y 999, inclusive.
- Definir una ruta de captura te permite enviar todas las solicitudes que no coincidan a un origen predeterminado o redireccionarlas a una página de destino o un extremo.
En el siguiente ejemplo, puedes ver que la ruta /live/us/ nunca coincidiría 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 este problema, debes asignar una prioridad más alta a la ruta más específica (más larga):
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 correctamente. Una solicitud con el prefijo /live/eu/ seguiría derivando a la ruta /live/ en la prioridad 2.
Filtrado de métodos
De forma predeterminada, Media CDN solo usa proxies de los métodos GET, HEAD y OPTIONS para tu origen y filtra los métodos que pueden modificarlo.
Puedes anular este comportamiento predeterminado para una regla de ruta específica si especificas
los métodos que deseas que se almacenen en proxy en 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 ruta, especifica una sección routeMethods que tenga 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
Normalización de rutas
La normalización de rutas describe cómo Media CDN combina varias representación de una URL en una sola representación canónica en situaciones específicas.
La normalización de rutas puede mejorar directamente las tasas de acierto de caché, ya que reduce la cantidad de URLs de solicitud que representan el mismo contenido y mitiga los errores de origen para los orígenes que esperan rutas normalizadas.
Las solicitudes entrantes se normalizan de la siguiente manera:
- Varias barras consecutivas se combinan en una sola. Por ejemplo, una ruta de URL de
/videos///12345/manifest.mpdse normaliza a/videos/12345/manifest.mpd. - Los segmentos de ruta se normalizan según RFC 3986, sección 6.2.2.3.
Por ejemplo, la ruta de acceso
/a/b/c/./../../gse normaliza a/a/gsegún el algoritmo "remove dot segments" definido en RFC 3986. Esta normalización se produce antes de verificar la caché o reenviar la solicitud al origen. - Las solicitudes no tienen una codificación de porcentaje normalizada. Por ejemplo, una URL con un carácter de barra codificado como porcentaje (
%2F) no se decodifica en el formato sin codificación.
Las URLs distinguen mayúsculas de minúsculas y no se normalizan. 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 para reescribir solicitudes y configurar redireccionamientos.
Reescribe las URLs de solicitud
Media CDN admite reescrituras de host y de ruta de acceso. Las reescrituras cambian la URL que se envía al origen y te permiten modificar los hosts y las rutas de acceso según sea necesario. Las reescrituras de host y ruta de acceso se encuentran a nivel de la ruta, lo que te permite definir qué solicitudes específicas se reescriben en función de cualquier comparador, incluidos la ruta de acceso, el parámetro de consulta y el encabezado de la solicitud.
Para obtener más detalles, consulta la especificación de la API de RouteAction.UrlRewrite.
A continuación, se muestran tres formas de reescribir una solicitud:
| Campo | Descripción |
|---|---|
urlRewrite.pathPrefixRewrite
|
Vuelve a escribir la ruta de acceso y quita el prefijo especificado en el
Solo se puede especificar una de |
urlRewrite.pathTemplateRewrite
|
Solo se puede especificar una de |
urlRewrite.hostRewrite
|
Vuelve a escribir el host antes de que se envíe la solicitud al servidor de origen. |
Notas:
- Las URLs reescritas no cambian la clave de caché. La clave de caché se basa en la URL de solicitud que envía el cliente.
- La reescritura se produce después de la coincidencia de rutas y la validación de solicitudes firmadas. Las rutas no se vuelven a hacer coincidir con otra regla de coincidencia.
Ejemplo: quita un prefijo de ruta de acceso
Por ejemplo, para volver a escribir la URL de solicitud de un cliente de /vod/videos/hls/1234/abc.ts a /videos/hls/1234/abc.ts (quitar /vod de la ruta), puedes usar la 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 prefijo de ruta que coincide en matchRules[].prefixMatch con el valor de pathPrefixRewrite.
Para reescribir un nombre de host (por ejemplo, reescribir cdn.example.com a 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 solicitud de origen cambiaría de cdn.example.com/videos/* a my-bucket.s3.us-west-2.amazonaws.com/videos/*.
También puedes combinar la reescritura de host y de ruta de acceso en una sola ruta.
Ejemplo: usa variables para reescribir URLs
Para usar pathTemplateMatch y pathTemplateRewrite para reescribir partes de una URL de solicitud entrante, consulta la sección Captura de variables.
Redirecciona solicitudes
Media CDN admite tres tipos de redireccionamientos:
- Redireccionamientos de host, que redireccionan solo el host (dominio) y mantienen la ruta de acceso y los parámetros de consulta sin cambios.
- Redireccionamientos de ruta de acceso, que reemplazan la ruta de acceso 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 que muestren diferentes códigos de estado de redireccionamiento por ruta.
La siguiente configuración es un ejemplo de un redireccionamiento basado en prefijos, en el 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
En este ejemplo, también se cambia el redireccionamiento a uno temporal, lo que evita que los clientes (como los navegadores) lo almacenen en caché. Esto puede ser útil si esperas cambiarlo en un futuro cercano.
Los valores de 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 mostrar un redireccionamiento al cliente. No puedes configurar los campos
originyurlRedirectal mismo tiempo. - Las rutas que redireccionan a HTTPS requieren que se adjunte al servicio al menos un certificado SSL.
Para obtener más detalles, consulta la especificación de la API de RouteRule.UrlRedirect.
Redirecciona todas las solicitudes a HTTPS
Para redireccionar todas las solicitudes a HTTPS (en lugar de HTTP), puedes configurar cada uno de tus servicios para que redireccione todas las solicitudes del cliente a HTTPS de forma automática. A los clientes que se conectan a través de HTTP se les envía una respuesta HTTP 301 (Permanent Redirect) con el encabezado Location configurado en la misma URL con “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 configurado ahora como true.
name: MY_SERVICE requireTls: true
También puedes configurar el encabezado Strict-Transport-Security como un encabezado de respuesta para dirigir a los clientes a 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 una arquitectura de múltiples nubes o si aún no migras datos a Cloud Storage con el Servicio de transferencia de almacenamiento.
Una configuración de origen mínima que configura un bucket alojado de forma virtual 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 tus recursos de EdgeCacheService, también debes configurar una reescritura de host para las rutas asociadas con este origen (o orígenes). De lo contrario, se usa el encabezado Host que establece la solicitud del cliente 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 de host en las solicitudes de origen, consulta la documentación sobre los encabezados de solicitud de origen.
Uso compartido de recursos entre dominios (CORS)
El uso compartido de recursos entre dominios (CORS) es un enfoque centrado en el navegador para realizar solicitudes entre dominios de forma segura.
Las políticas de CORS te permiten establecer automáticamente encabezados de CORS, como Access-Control-Allow-Origins, según una política por ruta.
Configurar CORS
La CDN de Media 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 establecer 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 realizar llamadas entre orígenes a tus servicios de Media CDN que pueden alojarse en un dominio (origen) diferente del frontend de tu sitio web y pueden evitar las solicitudes entre orígenes que no permites de forma explícita.
Por ejemplo, player.example.com y api.example.com son orígenes diferentes (en el sentido del navegador) y es posible que desees que tu aplicación de frontend realice solicitudes a api.example.com para recuperar la siguiente playlist o actualizar una ficha de contenido relacionado. Del mismo modo, es posible que player.example.com deba comunicarse con cdn.example.com para recuperar playlists y segmentos de video: cdn.example.com debe indicar que está bien y que player.example.com es un allowed origin, así como cualquier otra regla (encabezados permitidos, si se pueden incluir cookies).
A modo de ejemplo, si deseas permitir stream.example.com como origen y un encabezado X-Client-ID en las solicitudes de CORS, puedes configurar un corsPolicy en una 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 dentro de un EdgeCacheService. Cada routeRule puede definir un corsPolicy diferente según sea necesario o no definir ninguno.
Si defines un valor corsPolicy y también estableces un encabezado de respuesta personalizado con los campos responseHeadersToAdd en una ruta con el mismo nombre, el encabezado de respuesta personalizado tiene prioridad sobre el valor corsPolicy y se usa en su lugar.
Si la respuesta de origen establece encabezados HTTP y tienes configurado un valor de corsPolicy, se usarán los valores de corsPolicy. Los valores no se contraen ni se combinan para evitar enviar valores de encabezado no válidos a un cliente o configurar una política más permisiva de lo previsto de forma involuntaria.
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 una ruta para el encabezado Access-Control-Allow-Origin.
Para obtener más detalles, consulta la especificación de la API de RouteAction.CORSPolicy.
Campos de la 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 entrega desde |
Access-Control-Allow-Origins: https://stream.example.com
|
| maxAge |
Establece el encabezado de respuesta Algunos navegadores limitan este valor a 2 horas o menos, incluso si se especifica el valor máximo (86,400 s). |
Access-Control-Max-Age: 7200
|
| allowMethods |
Establece el encabezado de respuesta De forma predeterminada, Media CDN solo admite los métodos |
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 corsPolicy sin quitarlo. Las solicitudes de OPTIONS previas al vuelo se 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"
Soluciona problemas de enrutamiento
Si algunas solicitudes no recuperan resultados coincidentes o muestran errores, verifica lo siguiente:
- Una ruta debe tener un
matchRulecon exactamente uno deprefixMatch,fullPathMatchopathTemplateMatchdefinido. La API muestra un error si no incluyes uno de esos campos. - Asegúrate de que el
priorityde cada ruta esté configurado correctamente: las rutas más específicas (más largas) deben tener una prioridad más alta que las coincidencias de rutas más cortas y amplias. - De forma predeterminada, solo se admiten las solicitudes
GET,HEADyOPTIONS. Para configurar la compatibilidad con otros métodos, consulta Métodos de enrutamiento. Los métodos que no están habilitados para una ruta en particular se rechazan con un error HTTP405 (Method Not Allowed). - Las solicitudes HTTP
GETcon un cuerpo o cualquier solicitud con remolques se rechazan con un error HTTP400, ya que los cuerpos de solicitud no se permiten en las solicitudesGET. - La coincidencia de parámetros de consulta y encabezados es un “Y” lógico: la solicitud debe coincidir con todas las claves de parámetros de consulta o encabezados (y los valores, si se especifican) para coincidir con la ruta determinada.
¿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.
- Configura las solicitudes firmadas para autenticar el acceso al contenido.