Configura 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.

Configura una regla de ruta

Configura una regla de ruta para un servicio de Media CDN.

Solicitudes coincidentes

Una configuración de Media CDN contiene un conjunto de rutas definidas en la sección Enrutamiento de 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 usando encabezados y parámetros de consulta para desglosar tipos de manifiestos o usuarios específicos.

En el siguiente ejemplo, se muestra cómo enrutar solicitudes que coinciden 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 exactas, de prefijo y de comodín. La coincidencia de rutas de acceso se puede combinar con la coincidencia basada en el host, el encabezado y los parámetros de consulta para crear reglas de enrutamiento de solicitudes detalladas.

A continuación, se muestran tres formas de establecer coincidencias en una ruta de URL.

Para obtener más detalles, consulta la especificación de la API de MatchRule.

Por ejemplo, para que coincidan 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.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 devuelve un error HTTP 404, a menos que se haya configurado otra ruta o una ruta de captura.

Para obtener orientación sobre cómo funciona la precedencia en el caso de 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), usando una sintaxis de comodín.

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 que se envíe 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:

Notas:

• Si no reescribes una URL, usa los operadores más simples * y **.
• Cuando se usan variables para capturar segmentos de la ruta de acceso, no se puede hacer referencia a ninguna parte de la URL que no se haya capturado con una variable en un pathTemplateRewrite posterior. Para ver un ejemplo, consulta la sección captura de variables de ruta.
• No puedes hacer referencia a variables en un pathTemplateRewrite posterior que no existan en el pathTemplateMatch de 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 (comodines o variables) en una coincidencia. Los campos pathTemplateMatch y pathTemplateRewrite no 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 los operadores comodín: hacer coincidir todos los segmentos de ruta hasta un sufijo.

En ese caso, haz lo siguiente:

• Recupera los manifiestos de video (playlists) que terminan en .m3u8 y .mpd desde el 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 .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 Media CDN para admitir esta situación:

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 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 con segments/00001.ts y master.m3u8.
• En el pathTemplateRewrite en la misma ruta, vuelves a hacer referencia a algunas de las variables que capturaste en el pathTemplateMatch. Omites explícitamente las variables {country} y {lang} porque no coinciden con la estructura de directorios en el origen.

Con este ejemplo, sucede lo siguiente:

• Una URL de solicitud entrante de /us/en/hls/123139139/segment_00001.ts coincide con pathTemplateMatch y se reescribe como /123139139/hls/segment_00001.ts antes de enviarse al origen.
• La URL de una solicitud entrante de /us/123139139/master.m3u8 no coincide con pathTemplateMatch y recibe un código de estado 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 la coincidencia con comodines interactúa con la reescritura de URLs, consulta la sección sobre 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 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 publica una página 404 de HTTP 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 frente a contenido on demand). Dado que cada servicio tiene una sola política de seguridad, en general, recomendamos tener un servicio para cada mercado (ubicación geográfica) o carga de trabajo que tengas.

Notas:

• Los encabezados de host (o :authority de 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.com coincide con us.vod.example.com y us.vod.example.com:80.
• Si la solicitud se realiza 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 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 con 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 las claves de encabezado (y los valores, si se especifican) para que coincida 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 dentro de 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 incluyan este nombre de encabezado o que tengan un valor diferente no coinciden con esta ruta.

Para obtener más detalles, consulta la especificación de la API de HeaderMatch.

Del mismo modo, para que coincidan con los parámetros de búsqueda, 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 general (predeterminada)

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

Para configurar una ruta de captura general 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 acceso de la solicitud).
• Configura un origin o un urlRedirect (uno de los dos) en la ruta.

Por ejemplo, para configurar una ruta de captura general que dirija todas las solicitudes no coincidentes 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 cual" 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 con una prioridad más alta (número más pequeño). De lo contrario, una ruta que coincida con un prefijo de /stream/ con una prioridad de 1 impedirá que una ruta más específica de /stream/live/eu/ con una prioridad de 5 coincida con cualquier solicitud.

• La ruta con la 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 de cada regla debe establecerse en un número entre 1 y 999, inclusive.
• Definir una ruta de captura general te permite enviar todas las solicitudes que no coinciden a un origen predeterminado o redirigirlas 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, asigna 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 correctamente con las solicitudes. Una solicitud con el prefijo /live/eu/ aún se dirigiría a la ruta /live/ con prioridad 2.

Filtrado de métodos

De forma predeterminada, Media CDN solo utiliza los métodos GET, HEAD y OPTIONS como proxies 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 envíen a tu origen a través del proxy. Además de GET, HEAD y OPTIONS, Media CDN admite PUT, POST, DELETE y PATCH.

Media CDN solo vuelve a intentar o intenta la conmutación por error para las solicitudes que usan los métodos HTTP más seguros, como GET, HEAD o OPTIONS.

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 representaciones de una URL en una sola representación canónica en situaciones específicas.

La normalización de rutas de acceso puede mejorar directamente las tasas de acierto de caché, ya que reduce la cantidad de URLs de solicitudes que representan el mismo contenido y mitiga los errores de origen para los orígenes que esperan rutas de acceso 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.mpd se normaliza a /videos/12345/manifest.mpd.
• Los segmentos de ruta se normalizan según el RFC 3986, sección 6.2.2.3. Por ejemplo, la ruta de acceso /a/b/c/./../../g se normaliza a /a/g según el algoritmo "quitar segmentos de puntos" 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 siguen distinguiendo mayúsculas de minúsculas y no se normalizan en cuanto a mayúsculas y minúsculas. 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 de hosts y rutas de acceso. Las reescrituras cambian la URL que se envía al origen y te permiten modificar los hosts y las rutas según sea necesario. Las reescrituras de host y ruta de acceso se realizan 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:

Notas:

• Las URLs reescritas no cambian la clave de caché. La clave de caché se basa en la URL de la 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 comparar con otra regla de coincidencia.

Ejemplo: quita un prefijo de ruta de acceso

Por ejemplo, para reescribir la URL de una solicitud del cliente de /vod/videos/hls/1234/abc.ts a /videos/hls/1234/abc.ts (quitando /vod de la ruta de acceso), 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 de acceso 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 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 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 sobre captura de variables.

Redireccionar solicitudes

Media CDN admite tres tipos de redireccionamientos:

• Redireccionamientos de host, que redireccionan solo el host (dominio) y mantienen sin cambios la ruta y los parámetros de consulta
• 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 devuelvan diferentes códigos de estado de redireccionamiento por ruta.

La siguiente configuración es un ejemplo de redireccionamiento basado en prefijos, en el que se redirecciona 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, lo que evita que los clientes (como los navegadores) lo almacenen en caché. Esto puede ser útil si prevés cambiarlo en el futuro cercano.

Los valores de redirectResponseCode admitidos se muestran en la siguiente tabla.

Notas:

• Una ruta puede dirigir el tráfico a un origen o devolver un redireccionamiento al cliente. No puedes configurar los campos origin y urlRedirect al mismo tiempo.
• Las rutas que redireccionan a HTTPS requieren que se adjunte al menos un certificado SSL al servicio.

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 redireccionen automáticamente todas las solicitudes del cliente a HTTPS. Los clientes que se conectan a través de HTTP reciben un código de estado HTTP 301 (Permanent Redirect) con el encabezado Location establecido en la misma URL con "https://" en lugar de "http://".

gcloud edge-cache services update MY_SERVICE \
    --require-tls

Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

  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 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 tus recursos de EdgeCacheService, también debes configurar una reescritura de host para las rutas asociadas con este origen (o estos orígenes). De lo contrario, se usa el encabezado Host establecido por la solicitud del cliente cuando se recupera información del 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 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 multiorigen (CORS) es un enfoque centrado en el navegador para realizar solicitudes multiorigen 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

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 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 multiorigen a tus servicios de Media CDN que pueden estar alojados en un dominio (origen) diferente del frontend de tu sitio web y pueden impedir las solicitudes multiorigen que no permitas 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 lista 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 esto está bien y que player.example.com es un allowed origin, así como cualquier otra regla (encabezados permitidos, si se pueden incluir cookies).

Para tomar otro 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 ninguno.

Si defines un valor de 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 tendrá prioridad sobre el valor de corsPolicy y se usará en su lugar.

Si la respuesta del origen establece encabezados HTTP y tienes un valor corsPolicy establecido, se usarán los valores corsPolicy. Los valores no se contraen ni se combinan para evitar enviar valores de encabezado no válidos a un cliente o establecer, sin intención, una política más permisiva de lo previsto.

El {origin_request_header} especial se completa con el encabezado HTTP Origin en la solicitud del cliente. 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.

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 matchRule con exactamente uno de los valores 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 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, HEAD y OPTIONS. Para configurar la compatibilidad con otros métodos, consulta Métodos de rutas. Los métodos que no están habilitados para una ruta en particular se rechazan con un error HTTP 405 (Method Not Allowed).
• Las solicitudes HTTP GET con un cuerpo o cualquier solicitud con tráileres se rechazan con un error HTTP 400, ya que no se permiten cuerpos de solicitud en las solicitudes GET.
• 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 valores, si se especifican) para coincidir con la ruta determinada.

¿Qué sigue?

• Revisa la documentación sobre la configuración del 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.
• Para obtener más detalles sobre la configuración de recursos EdgeCacheService con Terraform, consulta la documentación del registro de Terraform.