Enrutamiento avanzado

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. Estas rutas coinciden con las solicitudes basadas en (al menos) un host y una ruta de acceso y el tráfico directo a un origen. Cada ruta puede definir su propia configuración de CDN, reescrituras, redireccionamientos, política de CORS, encabezados HTTP personalizados y asignación de origen. Las rutas pueden compartir orígenes.

Por ejemplo, puedes enrutar 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 mediante el uso de encabezados y parámetros de consulta para separar tipos de manifiestos o usuarios específicos.

En el siguiente ejemplo, se muestra cómo enrutar solicitudes que coinciden con un encabezado específico, un parámetro de consulta y un prefijo de ruta de acceso:

pathMatchers:
- name: routes
  routeRules:
  - priority: 10
    origin: staging-live-origin
    matchRules:
    - prefixMatch: /vod/
      headerMatches:
      - headerName: "x-staging-client"
        presentMatch: true
      queryParameterMatches:
      - name: "live"
        exactMatch: "yes"
    routeAction:
      cdnPolicy:
        defaultTtl: 5s

Coincidencia de ruta

Media CDN admite la coincidencia completa (exacta), el prefijo y la ruta de acceso del comodín. La coincidencia de ruta de acceso se puede combinar con la coincidencia basada en parámetros de consulta, host y encabezado para construir reglas de enrutamiento de solicitudes detalladas.

A continuación, se muestran tres formas de coincidencia 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 barras diagonales, si corresponde.

Una ruta con una regla de coincidencia de fullPathMatch: "/stream/" coincide con /stream/, pero no con /stream ni /stream/us/hls/1234.ts.

Una fullPathMatch es una coincidencia explícita (exacta).
matchRules[].prefixMatch La condición prefixMatch coincide con el prefijo de la ruta de URL. Las URL que comienzan con la misma string coinciden.

Una ruta con una regla de coincidencia de prefixMatch: "/videos/" coincide con /videos/hls/58481314/manifest.m3u8 y con /videos/dash porque ambas contienen el prefijo /videos/.
matchRules[].pathTemplateMatch La condición pathTemplateMatch admite operadores de comodines, lo que te permite hacer coincidir patrones de URL complejos y segmentos de ruta de acceso, así como capturar variables con nombre para volver a escribir las URL.

Una ruta con una regla de coincidencia de pathTemplateMatch: "/**.m3u8" coincide con cualquier ruta de URL que termine en .m3u8.

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

Para obtener más ejemplos, consulta la sección coincidencia de patrones.

Por ejemplo, para hacer coincidir todas las solicitudes que comienzan con /stream/, crea una regla de enrutamiento similar a la siguiente:

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      matchRules:
      - prefixMatch: /stream/

En este ejemplo, se incluye explícitamente la barra diagonal final en la regla de coincidencia:

  • Una solicitud a media.example.com/stream/id/1234/hls/manifest.m3u8 coincide con esta ruta.
  • Una solicitud a media.example.com/stream-eu/id/4567/hls/manifest.m3u8 no coincide con esta ruta.

En el segundo caso, Media CDN muestra un error HTTP 404, a menos que haya otra ruta o una ruta genérica configurada.

A fin de obtener orientación sobre cómo funciona la prioridad para las rutas con prefijos similares, consulta la sección 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 los sufijos (extensiones de archivo), mediante una sintaxis de comodín simple.

También puedes asociar uno o más componentes 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 los componentes de la URL antes de que la solicitud se envíe al origen.

En el ejemplo siguiente, 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 compatible incluye lo siguiente.

Operador Coinciden Ejemplo
* Coincide con un solo componente de ruta de acceso hasta el siguiente separador de ruta de acceso: / /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 componente de ruta de acceso hasta el siguiente separador de ruta de acceso: /.

/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 componente de la 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 propaga la variable de ruta language con el valor lang/en.
{name=**}

Una variable con nombre que coincide con cero o más segmentos de ruta.

Si está presente, debe ser el último operador.

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

/videos/{file=**} coincide con /videos/en-GB/def566/manifest.m3u8, incluida la extensión, y captura la variable de ruta file="en-GB/def566/manifest.m3u8.

Notas:

  • Si no reescribes una URL, usa los operadores * y ** más simples.
  • Cuando se usan variables para capturar componentes de la ruta de acceso, cualquier parte de la URL que una variable no capture no se puede hacer referencia en una pathTemplateRewrite posterior. Para ver un ejemplo, consulta la sección Captura variables de ruta de acceso.
  • No puedes hacer referencia a variables en un pathTemplateRewrite posterior que no existan en pathTemplateMatch en la misma ruta.
  • Las variables distinguen entre mayúsculas y minúsculas, con {FORMAT}, {forMAT} y {format} que representan diferentes variables y valores.
  • Puedes especificar hasta cinco operadores (comodines o variables) en una coincidencia. Los campos pathTemplateMatch y pathTemplateRewrite no deben exceder los 256 caracteres.

Ejemplo: coincidencia en una extensión de archivo

En el siguiente ejemplo, se muestra un caso práctico común para los operadores comodín: hacer coincidir todos los componentes de la ruta de acceso hasta un sufijo.

En este caso, debes hacer lo siguiente:

  • Recupera los manifiestos de video (listas de reproducción) que terminan en .m3u8 y .mpd del origen del manifiesto y aplica un TTL corto (5 segundos) a estas respuestas porque cambian con regularidad.
  • Recupera los segmentos de video que terminan en .ts y .m4s desde el 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 CDN de Media para admitir esto:

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    # the first route only matches video manifests
    - priority: 1
      matchRules:
      - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments
      - pathTemplateMatch: "/**.mpd"
      origin: manifest-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 5s
    # the second route matches video segments, fetches them
    # from a separate origin server, caching them for a longer
    # duration (1 day).
    - priority: 2
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: segment-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 86400s

Ejemplo: captura de variables de ruta

En el siguiente ejemplo, se muestra cómo usar variables con nombre para describir uno o más componentes de la ruta de acceso.

Estas variables se pueden usar en una pathTemplateRewrite para reescribir la ruta de acceso antes de que la solicitud se envíe al origen, o para que una pathTemplateMatch compleja se describa de forma automática.

routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      matchRules:
      # Matches a request of "/us/en/hls/123139139/segments/00001.ts"
      - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}"
      origin: my-origin
      routeAction:
        urlRewrite:
          # Rewrites to "/123139139/hls/segments/00001.ts"
          pathTemplateRewrite: "/{id}/{format}/{file}"

En particular, haz lo siguiente:

  • Cada variable {name} captura un solo segmento de ruta. 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 con segments/00001.ts y con master.m3u8.
  • En pathTemplateRewrite en la misma ruta, consulta algunas de las variables que capturaste en pathTemplateMatch. Omites de forma explícita las variables {country} y {lang} porque no coinciden con la estructura del directorio en el origen.

Con este ejemplo, ocurre lo siguiente:

  • Una URL de solicitud entrante de /us/en/hls/123139139/segment_00001.ts coincide con pathTemplateMatch y se reescribe antes de /123139139/hls/segment_00001.ts antes de enviarse 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 como /c966cbbe6ae3/dash/subtitle_00001.vtt antes de enviarse al origen.

Para obtener más información sobre cómo interopera la coincidencia de comodines con la reescritura de URL, 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 de acceso). En el caso más común, todos los nombres de host para un servicio se asignan a un solo conjunto de rutas compartidas con una sola lista de hosts y un solo comparador de rutas de acceso.

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    # list of routes for the configured hosts
    - priority: 999
      matchRules:
      - prefixMatch: /
      origin: DEFAULT_ORIGIN

Los hosts que no coinciden reciben 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 en vivo en función de la demanda). 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 HTTP/2 :authority) 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.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.

Coincidencia en encabezados y parámetros de consulta

Puedes configurar rutas para que coincidan con nombres de parámetros de consulta y encabezados específicos, así como con la presencia de un valor de encabezado (prefijo, sufijo o coincidencia exacta).

La coincidencia del parámetro de consulta y del encabezado son “AND” lógicas: la solicitud debe coincidir con todos los parámetros de consulta y las claves de encabezado (y los valores, si se especifica) para que coincidan 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 las condiciones de coincidencia dentro de routeRules[].matchRules[].headerMatches[]:

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: alternate-origin
      matchRules:
      - prefixMatch: "/videos/"
        headerMatches:
        - headerName: "x-device-name"
          exactMatch: "roku"

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 con un valor diferente no coinciden con esta ruta.

Del mismo modo, 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: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: eu-live-origin-prod
      matchRules:
      - prefixMatch: "/videos/"
        queryParameterMatches:
        - name: "playback_type"
          exactMatch: "live"
        - name: "geo"
          exactMatch: "eu"

En este ejemplo, una solicitud de cliente https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu coincide con esta ruta.

Define una ruta genérica (predeterminada)

De forma predeterminada, Media CDN muestra un error HTTP 404 (Not Found) si una solicitud no coincide con ninguna ruta configurada.

A fin de configurar una ruta catch-all para una pathMatcher determinada (colección de rutas), haz lo siguiente:

  • Crea un routeRule con la prioridad más baja (el número más alto), por ejemplo, 999, que es la prioridad de ruta más baja posible.
  • Configura un matchRule con una coincidencia de prefijo de / (coincide con todas las rutas de solicitud).
  • 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 llamadomy-origin, crea una ruta nueva conpriority: 999 y unmatchRules[].prefixMatch de/ de la siguiente manera:

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 999
      origin: my-origin
      matchRules:
      - prefixMatch: /

De manera opcional, puedes volver a escribir la URL antes de la recuperación de origen o redireccionar a una página predeterminada (como tu página de destino) en lugar de enviar la solicitud “tal cual” al origen.

Orden y prioridad de ruta

Cada ruta en un arreglo 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 pequeño). Una ruta que coincide con un prefijo /stream/ de una prioridad de 1 evita que una ruta más específica de /stream/live/eu/ con una prioridad de 5 coincida con las solicitudes.

  • 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 general te permite enviar todas las solicitudes no coincidentes a un origen predeterminado o redireccionarlas a una página o extremo de destino.

En el siguiente ejemplo, puedes ver que la ruta /live/us/ nunca coincidiría, ya que 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 abordar 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/ sería la ruta /live/ con una prioridad 2.

Normalización de rutas

La normalización de rutas describe cómo Media CDN combina varias representaciones 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 aciertos de caché, ya que reduce la cantidad de URL de solicitud que representan el mismo contenido y mitiga los errores de origen para orígenes que esperan rutas normalizadas.

Las solicitudes entrantes se normalizan de la siguiente manera:

  • Las múltiples barras consecutivas se combinan en una sola barra. Por ejemplo, una ruta de URL de /videos///12345/manifest.mpd se normaliza en /videos/12345/manifest.mpd.
  • Los segmentos de ruta se normalizan de acuerdo con la RFC 3986 sección 6.2.2.3. Por ejemplo, la ruta de acceso /a/b/c/./../../g se normaliza en /a/g según el algoritmo “quitar segmentos de puntos” definido en RFC 3986. Esta normalización ocurre antes de verificar la caché o reenviar la solicitud al origen.
  • Las solicitudes no se codifican en porcentaje con normalidad. Por ejemplo, una URL con un carácter de barra codificado por porcentaje (%2F) no se decodifica en el formato sin codificación.

Las URL distinguen entre mayúsculas y 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 sobre cómo reescribir solicitudes y configurar redireccionamientos.

Reescribe las URLs de solicitud

Media CDN admite la reescritura del host y la ruta de acceso. Las reescrituras cambian la URL enviada 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 están a nivel de 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.

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 prefixMatch que coincidió con la solicitud.

Solo se puede especificar pathPrefixRewrite o pathTemplateRewrite en una sola regla de enrutamiento.

urlRewrite.pathTemplateRewrite

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

Solo se puede especificar pathPrefixRewrite o pathTemplateRewrite en una sola regla de enrutamiento.

urlRewrite.hostRewrite Reescribe el host antes de que la solicitud se envíe al servidor de origen.

Notas:

  • Las URL reescritas no cambian la clave de caché. La clave de caché se basa en la URL de solicitud enviada por el cliente.
  • La reescritura se produce después de la coincidencia de las rutas y la validación de la solicitud firmada. Las rutas no coinciden 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 (que quita /vod de la ruta de acceso), puedes usar la función pathPrefixRewrite:

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/vod/videos/"
      routeAction:
        urlRewrite:
          pathPrefixRewrite: "/videos/"

Una pathPrefixRewrite funciona mediante el reemplazo de todo el componente de ruta de acceso en matchRules[].prefixMatch por el valor de pathPrefixRewrite.

Para volver a escribir un nombre de host (por ejemplo, volver a escribir 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: routes
  pathMatchers:
  - name: 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 cdn.example.com/videos/* a my-bucket.s3.us-west-2.amazonaws.com/videos/*. También puedes combinar las reescrituras de host y ruta de acceso en una sola ruta.

Ejemplo: usa variables para reescribir URLs

Si deseas usar pathTemplateMatch y pathTemplateRewrite para reescribir partes de una URL de solicitud entrante, consulta la sección Captura variables.

Solicitudes de redireccionamiento

Media CDN admite tres tipos de redireccionamientos:

  • Redireccionamientos de host, que redireccionan solo el host (dominio), lo que mantiene los parámetros de ruta y de consulta sin cambios.
  • Redireccionamientos de ruta, que reemplazan la ruta por completo.
  • Redireccionamientos de prefijos de ruta, que solo reemplazan el prefijo coincidente.

Los redireccionamientos predeterminados se establecen en HTTP 301 (Moved Permanently), pero se pueden configurar para que muestren diferentes códigos de estado de redireccionamiento en función de la ruta.

La siguiente configuración es un ejemplo de un redireccionamiento basado en prefijos sencillo, 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: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 10
      origin: my-origin
      matchRules:
      - prefixMatch: "/on-demand/"
      routeAction:
        urlRedirect:
          # The prefix matched in matchRules.prefixMatch is replaced
          # by this value
          prefixRedirect: "/streaming/"
          redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307

Este ejemplo también cambia el redireccionamiento a un redireccionamiento 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 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 origin y routeAction.urlRedirect al mismo tiempo.
  • Las rutas que redireccionan a HTTPS requieren que al menos un certificado SSL esté conectado al servicio.

Redirecciona todas las solicitudes a HTTPS

Para redireccionar todas las solicitudes a HTTPS (en lugar de HTTP), puedes configurar cada uno de tus servicios a fin de que redireccionen todas las solicitudes de clientes a HTTPS de forma automática. Los clientes que se conectan a través de HTTP reciben una respuesta HTTP 301 (Permanent Redirect) con el encabezado Location configurado 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 en 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 siempre a través de HTTPS directamente.

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 EdgeCacheService, también debes configurar una reescritura del host para las rutas asociadas con este origen (o orígenes). De lo contrario, se usa el encabezado del host que configura la solicitud del cliente cuando se recupera desde el origen.

Por ejemplo, para asignar todas las solicitudes con un prefijo de ruta de acceso /legacy/ a tu bucket externo, puedes configurar hostRewrite y pathPrefixRewrite a fin de 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 la documentación de los encabezados de las solicitudes de origen.

Uso compartido de recursos entre dominios (CORS)

Las políticas de uso compartido de recursos entre dominios (CORS) te permiten establecer de forma automática los encabezados de CORS, como Access-Control-Allow-Origins, en función de una política por ruta.

Estos encabezados te permiten realizar llamadas entre dominios a tus servicios de Media CDN, que pueden estar alojadas en un dominio (origen) diferente del frontend de tu sitio web, y evitar solicitudes de origen cruzado que no permite explícitamente.

Las políticas de CORS se configuran como parte de EdgeCacheService y se pueden configurar por ruta.

Configurar CORS

En la siguiente tabla, se describen los campos que componen una política de CORS:

Campo Descripción Ejemplo
allowOrigins

Configura el encabezado de respuesta Access-Control-Allow-Origins, que especifica qué orígenes pueden realizar solicitudes entre dominios en un entorno de navegador.

Por ejemplo, si tu contenido de video se entrega desde https://video.example.com, pero tu portal orientado al usuario se entrega 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 por cuánto tiempo, en segundos, un cliente del navegador debe almacenar en caché la respuesta a una solicitud de comprobación previa de CORS.

Algunos navegadores limitan esto a 2 horas o menos, incluso si se especifica el valor máximo (86,400).

 Access-Control-Max-Age: 7200
allowMethods

Configura el encabezado de respuesta Access-Control-Allow-Methods, que especifica qué métodos HTTP pueden acceder al recurso.

Media CDN solo es compatible con los métodos GET, HEAD y OPTIONS.

 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

Configura el encabezado de respuesta Access-Control-Expose-Headers, que determina a qué encabezados puede acceder el JavaScript del cliente.

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

Configura el encabezado de respuesta Access-Control-Allow-Credentials, que permite que JavaScript del lado del cliente inspeccione la respuesta para las solicitudes con credenciales incluidas.

Este encabezado se omite cuando se establece en falso.

 Access-Control-Allow-Credentials: true
disabled Inhabilita la corsPolicy sin quitarla. Las solicitudes OPTIONS de verificación previa se envían al origen mediante proxy. N/A

Ejemplo de corsPolicy

En el siguiente ejemplo de configuración, se muestra una configuración básica 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"

Para obtener más información sobre CORS, lee este artículo de CORS en web.dev.

Soluciona problemas de enrutamiento

Si algunas solicitudes no coinciden con lo esperado o muestran errores, haz lo siguiente:

  • Una ruta debe tener un matchRule con exactamente uno de prefixMatch, fullPathMatch o pathTemplateMatch definidos. La API muestra un error si no incluyes uno de esos campos.
  • Asegúrate de que el priority de cada ruta se configure correctamente: las rutas más específicas (más largas) deben tener una prioridad más alta sobre las coincidencias de ruta más cortas y amplias.
  • Solo se admiten solicitudes GET, HEAD y OPTIONS. otros métodos HTTP se rechazan con un error HTTP 405 (Method Not Allowed).
  • Las solicitudes HTTP GET con un cuerpo o cualquier solicitud con avances se rechazan con un error HTTP 400, porque los cuerpos de solicitud no están permitidos en las solicitudes GET.
  • La coincidencia del parámetro de consulta y del encabezado son "AND" lógicas: la solicitud debe coincidir con todas las claves (y los valores) del encabezado o el encabezado de la consulta para que coincidan con la ruta determinada.

¿Qué sigue?