Configura las rutas de servicio

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 fullPathMatch: "/stream/" coincide con /stream/, pero no con /stream ni /stream/us/hls/1234.ts

Un fullPathMatch es una coincidencia explícita (exacta).
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 prefixMatch: "/videos/" coincide con /videos/hls/58481314/manifest.m3u8 y /videos/dash porque ambas contienen el /videos/ .
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 pathTemplateMatch: "/**.m3u8" coincide con cualquier ruta de URL que termine con .m3u8.

Tanto /content/en-GB/13/51491/manifest_193193.m3u8 como /p/abc/1234/manifest_1080p5000.m3u8 coinciden con este patrón.

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.

/**.m3u8 o /{path=**}.m3u8 coinciden con todo. los segmentos de ruta hasta la extensión.

/videos/{file=**} coincidencias /videos/en-GB/def566/manifest.m3u8, incluido el y captura la variable de ruta de acceso file="en-GB/def566/manifest.m3u8.

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 el pathTemplateMatch 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 y pathTemplateRewrite 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 con segments/00001.ts y con master.m3u8.
  • En el pathTemplateRewrite de la misma ruta, puedes hacer referencia a algunos de las variables que capturaste en pathTemplateMatch. 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 el pathTemplateMatch 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 con pathTemplateMatch y recibe una respuesta HTTP 404 (Not Found).
  • Una URL de solicitud entrante de /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt también coincide con pathTemplateMatch 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 con us.vod.example.com y us.vod.example.com:80
  • Si la solicitud es a través de HTTPS (TLS), una entrada hostRules[].hosts[] de *.vod.example.com coincide con us.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 o urlRedirect 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 prefixMatch que coincidió con la solicitud.

Solo una de las siguientes opciones: pathPrefixRewrite o pathTemplateRewrite pueden especificarse en una sola regla de enrutamiento.

urlRewrite.pathTemplateRewrite

pathTemplateRewrite solo se puede usar con un regla de coincidencia pathTemplateMatch correspondiente en la misma ruta.

Solo una de las siguientes opciones: pathPrefixRewrite o pathTemplateRewrite pueden especificarse en una sola regla de enrutamiento.

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 y urlRedirect 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 Access-Control-Allow-Origins. que especifica los orígenes que pueden realizar solicitudes de origen cruzado en un del navegador.

Por ejemplo, si tu contenido de video se publica desde https://video.example.com, pero el portal para el usuario está publicado desde https://stream.example.com, debes agregar https://stream.example.com como origen permitido

Access-Control-Allow-Origins: https://stream.example.com
maxAge

Establece el encabezado de respuesta Access-Control-Max-Age, que especifica cuánto tiempo, en segundos, un cliente de navegador debe almacenar en caché el respuesta a una solicitud preliminar de CORS.

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 Access-Control-Allow-Methods. que especifica los métodos HTTP que pueden acceder al recurso.

De forma predeterminada, Media CDN solo admite GET, HEAD y OPTIONS. En Vista previa, para configurar la compatibilidad con otros métodos, consulta Métodos de ruta:

 Access-Control-Allow-Methods: GET, OPTIONS, HEAD
allowHeaders

Establece el encabezado Access-Control-Allow-Headers, que determina qué encabezados se pueden enviar en una solicitud de CORS.

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 Access-Control-Expose-Headers. que determina a qué encabezados puede acceder el cliente JavaScript:

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 Access-Control-Allow-Credentials. que permite que el código JavaScript del cliente inspeccione la respuesta de las solicitudes. con credenciales incluidas.

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 de prefixMatch, Se definen fullPathMatch o pathTemplateMatch. 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 y OPTIONS. 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 HTTP 405 (Method Not Allowed)
  • Se rechazan las solicitudes GET HTTP con un cuerpo o cualquier solicitud con avances. con un error HTTP 400, ya que los cuerpos de las solicitudes no están permitidos en GET 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?