Configurar rutas de servicio

Media CDN proporciona funciones avanzadas de enrutamiento HTTP que le permiten asignar el tráfico a configuraciones perimetrales y orígenes específicos de manera pormenorizada.

Configurar una regla de ruta

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

Consola

  1. En la Google Cloud consola, ve a la página Media CDN.

    Ir a Media CDN

  2. Para abrir la página Detalles del servicio en el que quiere configurar una regla de ruta, haga clic en el nombre del servicio.

  3. Para cambiar al modo de edición, haz clic en el botón Editar.

  4. Para ir a la sección Enrutamiento, haz clic en Siguiente.

  5. Especifique al menos una regla de host. Haz clic en Añadir regla de host. A continuación, haz lo siguiente:

    1. En Hosts, especifica al menos un host para la coincidencia.

    2. En Descripción, escribe una breve descripción de la regla de host.

    También puedes hacer clic en la flecha para desplegar una regla de host y editarla.

  6. Especifique al menos una regla de ruta. Haz clic en Añadir regla de ruta.

    También puedes editar una regla de ruta haciendo clic en Editar en la fila correspondiente.

  7. En el panel Editar regla de ruta, en Prioridad, asigna un valor a la prioridad de la ruta.

  8. En Descripción, escribe una breve descripción que te ayude a identificar la regla en una lista de reglas.

  9. En la sección Coincidencia, especifique al menos una condición de coincidencia. Haz clic en Añadir una condición de coincidencia. A continuación, haz lo siguiente:

    1. En Tipo de concordancia, selecciona cualquier opción de concordancia de ruta.
    2. En Coincidencia de ruta, especifique los nombres, las rutas o las plantillas. Considera la posibilidad de usar la coincidencia con patrones comodín.

      Si es necesario, selecciona también Habilitar distinción entre mayúsculas y minúsculas para el valor de la ruta.

    3. Opcional: Seleccione Los encabezados coinciden y Los parámetros de consulta coinciden. A continuación, haz clic en los botones correspondientes para añadir encabezados y parámetros de consulta. En cada uno, especifique el nombre, el tipo de concordancia y el valor.

      Para obtener más información, consulta Coincidencia con encabezados y parámetros de consulta.

    4. Para guardar la condición de coincidencia, haz clic en Hecho.

  10. En Acción principal, selecciona una de las siguientes opciones:

    • Obtener de un origen: para dirigir las solicitudes a un origen específico, selecciona esta opción y, a continuación, elige un origen.

    • Redirección de URL: para redirigir solicitudes, seleccione esta opción. A continuación, especifica el tipo de redirección, la ruta y el código de estado.

      De forma opcional, selecciona las opciones para redirigir todas las respuestas a HTTPS o para quitar la consulta.

  11. Haz clic en Configuraciones avanzadas.

    1. En la sección Acción del encabezado, haz clic en Añadir un elemento.

      Seleccione un tipo de acción y, a continuación, especifique un encabezado como par de nombre y valor. A continuación, haga clic en Hecho.

    2. En la sección Acción de ruta, haz clic en Añadir un elemento.

      Especifica un tipo de acción y sus opciones relacionadas. A continuación, haga clic en Hecho.

  12. En Filtrado por método HTTP, seleccione Personalizar filtrado por método HTTP.

    A continuación, selecciona los métodos HTTP que quieras que se envíen a tu origen a través del proxy.

  13. Para guardar la regla de ruta, haz clic en Guardar.

  14. Para guardar los cambios en el servicio, haz clic en Actualizar servicio.

gcloud y YAML

  1. Exporta tu configuración de Media CDN a un archivo YAML. Usa el comando gcloud edge-cache services export.

    gcloud edge-cache services export SERVICE_NAME \
        --destination=FILENAME.yaml
    

    Haz los cambios siguientes:

    • SERVICE_NAME: el nombre de tu servicio
    • FILENAME : el nombre del archivo YAML
  2. Actualice el archivo YAML con la configuración necesaria, tal como se describe en las secciones de esta página.

  3. Para actualizar el servicio, importa tu configuración de Media CDN desde el archivo YAML. Usa el comando gcloud edge-cache services import.

    gcloud edge-cache services import SERVICE_NAME \
        --source=FILENAME.yaml
    

Solicitudes de coincidencia

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 información 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, redirecciones, 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 mediante encabezados y parámetros de consulta para separar tipos de manifiesto o usuarios específicos.

En el siguiente ejemplo se muestra cómo enrutar solicitudes que coincidan con un encabezado, un parámetro de consulta y un prefijo de ruta específicos para el host media.example.com:

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      origin: staging-live-origin
      matchRules:
      - prefixMatch: /vod/
        headerMatches:
        - headerName: "x-staging-client"
          presentMatch: true
        queryParameterMatches:
        - name: "live"
          exactMatch: "yes"
      routeAction:
        cdnPolicy:
          defaultTtl: 5s

Coincidencia de ruta

Media CDN admite la coincidencia de rutas completa (exacta), de prefijo y con comodines. La coincidencia de rutas se puede combinar con la coincidencia basada en host, encabezado y parámetros de consulta para crear reglas de enrutamiento de solicitudes precisas.

A continuación, se indican tres formas de buscar 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 barras diagonales al final, si procede.

Una ruta con una regla de coincidencia de fullPathMatch: "/stream/" coincide con /stream/, pero no con /stream ni con /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 la URL. Las URLs que empiezan por la misma cadena coinciden.

Una ruta con una regla de coincidencia prefixMatch: "/videos/" coincide con /videos/hls/58481314/manifest.m3u8 y /videos/dash porque ambas contienen el prefijo /videos/.

matchRules[].pathTemplateMatch La condición pathTemplateMatch admite operadores comodín, lo que le permite buscar coincidencias con patrones de URL y segmentos de ruta complejos, así como capturar variables con nombre para reescribir URLs.

Una ruta con una regla de coincidencia pathTemplateMatch: "/**.m3u8" coincide con cualquier ruta de URL que termine en .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 la sección Coincidencia de patrones.

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

Por ejemplo, para que coincidan todas las solicitudes que empiecen por /stream/, cree 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 inclinada 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 comodín.

Para obtener información sobre cómo funciona la precedencia en las rutas con prefijos similares, consulta la sección Prioridad y orden de ruta.

Coincidencia con patrones (comodines)

La coincidencia de patrones le permite buscar coincidencias con varias partes de una URL, incluidas las URL parciales y los sufijos (extensiones de archivo), mediante la sintaxis de comodines.

También puede asociar uno o varios segmentos de ruta con variables con nombre en un campo pathTemplateMatch y, a continuación, hacer referencia a esas variables al reescribir la URL en un campo pathTemplateRewrite. Esto le permite reordenar y eliminar segmentos de URL antes de que se envíe la solicitud a su origen.

En el siguiente ejemplo se muestra cómo puedes hacer coincidir dos sufijos de URL diferentes:

# EdgeCacheService.routing.pathMatchers[]
    routeRules:
    - priority: 1
      description: "Match video segments"
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: prod-video-storage

La sintaxis admitida incluye lo siguiente:

Operador Coincide con Ejemplo
* Coincide con un solo segmento de ruta hasta el siguiente separador de ruta: / /videos/*/*/*.m4s coincide con /videos/123414/hls/1080p5000_00001.m4s.
** Coincide con cero o más segmentos de ruta. Si está presente, debe ser el último operador. /**.mpd coincide con /content/123/india/dash/55/manifest.mpd.
{name} or {name=*}

Una variable con nombre que coincide con un segmento de ruta.

Coincide con un solo segmento de ruta hasta el siguiente separador de ruta: /.

/content/{format}/{lang}/{id}/{file}.vtt coincide /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. El segmento de ruta que coincide con videos/* se captura como variable con nombre. /videos/{language=lang/*}/* coincide con /videos/lang/en/video.m4s y rellena 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 coincide 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 vas a reescribir una URL, usa los operadores * y **, que son más sencillos.
  • Cuando se usan variables para capturar segmentos de ruta, las partes de la URL que no se capturan con una variable no se pueden hacer referencia en un pathTemplateRewrite posterior. Para ver un ejemplo, consulta la sección Capturar 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 entre mayúsculas y minúsculas. {FORMAT}, {forMAT} y {format} representan variables y valores diferentes.
  • Puede especificar hasta 10 operadores (comodines o variables) en una coincidencia. Los campos pathTemplateMatch y pathTemplateRewrite no deben superar los 255 caracteres.

Ejemplo: buscar coincidencias en una extensión de archivo

En el siguiente ejemplo se muestra un caso práctico habitual de los operadores comodín: hacer coincidir todos los segmentos de ruta hasta un sufijo.

En este caso, haz lo siguiente:

  • Obtiene los manifiestos de vídeo (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 frecuencia.
  • Obtiene los segmentos de vídeo que terminan en .ts y .m4s del origen del segmento y aplica un TTL más largo (1 día) a estas respuestas.

Este enfoque se suele utilizar cuando se usan servicios de SSAI (inserción de anuncios en el servidor) o DAI (inserción dinámica de anuncios), así como en vídeos en directo en los que el archivo de manifiesto se actualiza cada pocos segundos.

En la siguiente configuración se muestra cómo configurar el enrutamiento de Media CDN para admitir esta opció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: Capturar variables de ruta

En el siguiente ejemplo se muestra cómo usar variables con nombre para describir uno o varios segmentos de ruta.

Estas variables se pueden usar en un pathTemplateRewrite para reescribir la ruta antes de que se envíe la solicitud al origen o para que un pathTemplateMatch complejo se describa por 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 concreto, este cambio afecta a las siguientes acciones:

  • Cada variable {name} captura un segmento de ruta. Un segmento de ruta es el conjunto de caracteres que se encuentran entre dos barras diagonales (/) 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 la pathTemplateRewrite de la misma ruta, haces referencia a algunas de las variables que has recogido en la pathTemplateMatch. Omite explícitamente las variables {country} y {lang} porque no coinciden con la estructura de directorios del origen.

En este ejemplo, ocurre 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 solicitud entrante /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 interactúa la coincidencia con comodines con la reescritura de URLs, consulte 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 (denominados coincidencia de ruta). En el caso más habitual, todos los nombres de host de un servicio se asignan a un único conjunto de rutas compartidas con una única lista de hosts y un único 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 coincidan se les servirá una página HTTP 404 predeterminada. Para aceptar cualquier host, puedes incluir el carácter comodín * como entrada hostRules[].hosts[].

También puedes definir grupos de rutas (por ejemplo, por país o por si son en directo o bajo demanda). Como cada servicio tiene una sola política de seguridad, generalmente recomendamos tener un servicio por cada mercado (zona geográfica) o carga de trabajo.

Notas:

  • Los encabezados Host (o HTTP/2 :authority) que contienen un puerto se comparan implícitamente con un host configurado. No es necesario que especifiques los puertos.
  • Si la solicitud se realiza 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 información, consulta la especificación de la API de HostRule.

Coincidencia con encabezados y parámetros de consulta

Puedes configurar rutas para que coincidan con nombres de encabezados y parámetros de consulta específicos, 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 lógica "AND": la solicitud debe coincidir con todos los parámetros de consulta y las claves de encabezado (y los valores, si se especifican) para coincidir con la ruta determinada.

Por ejemplo, si quiere enrutar solicitudes con un nombre de campo de encabezado y un valor de encabezado específicos a un origen llamado alternate-origin, configure sus condiciones de coincidencia en routeRules[].matchRules[].headerMatches[]:

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

En este ejemplo, las solicitudes con /videos/ al principio 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 coincidirán con esta ruta.

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

Del mismo modo, para buscar coincidencias con parámetros de consulta, especifique uno o varios 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 de 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 la especificación de la API de QueryParameterMatcher.

Definir una ruta catch-all (predeterminada)

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

Para configurar una ruta general en un pathMatcher (conjunto 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 concordancia de prefijo de / (concordancia con todas las rutas de solicitud).
  • Configura una origin o una urlRedirect en la ruta.

Por ejemplo, para configurar una ruta catch-all que dirija todas las solicitudes no coincidentes a un origen predeterminado llamado my-origin, crea una 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: /

También puedes reescribir la URL antes de la obtención del origen o redirigir a una página predeterminada (como tu página de destino) en lugar de enviar la solicitud "tal cual" al origen.

Prioridad y orden de ruta

Cada ruta de una matriz de routeRules[] debe tener un priority asociado.

Las rutas más específicas deben tener una prioridad más alta (un número más pequeño). Una ruta que coincida con el prefijo /stream/ y tenga una prioridad de 1 impide que una ruta más específica de /stream/live/eu/ con una prioridad de 5 coincida con ninguna solicitud.

  • La ruta de mayor prioridad es "1" y la de menor es "999".
  • No puedes configurar dos o más routeRules con la misma prioridad. La prioridad de cada regla debe ser un número entre 1 y 999 (ambos incluidos).
  • Si defines una ruta catch-all, puedes enviar todas las solicitudes que no coincidan a un origen predeterminado o redirigirlas a una página de destino o a un endpoint.

En el siguiente ejemplo, puede ver que la ruta /live/us/ nunca se correspondería porque la ruta /live/ tiene una prioridad mayor:

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: /

De esta forma, la ruta más específica puede coincidir con las solicitudes correctamente. Una solicitud que empiece por /live/eu/ seguirá pasando a la ruta /live/ con prioridad 2.

Filtrado de métodos

De forma predeterminada, Media CDN solo proxyiza los métodos GET, HEAD y OPTIONS a su origen y filtra los métodos que pueden modificarlo.

Puedes anular este comportamiento predeterminado en una regla de ruta específica indicando los métodos que quieras que se 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 de 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 combina Media CDN varias representaciones de una URL en una única representación canónica en situaciones específicas.

La normalización de rutas puede mejorar directamente los porcentajes de aciertos de caché al reducir el número de URLs de solicitud que representan el mismo contenido y al mitigar los errores de origen en los orígenes que esperan rutas normalizadas.

Las solicitudes entrantes se normalizan de la siguiente manera:

  • Varias barras diagonales consecutivas se combinan en una sola. Por ejemplo, una ruta de URL de /videos///12345/manifest.mpd se normaliza como /videos/12345/manifest.mpd.
  • Los segmentos de ruta se normalizan de acuerdo con la sección 6.2.2.3 del RFC 3986. Por ejemplo, la ruta /a/b/c/./../../g se normaliza a /a/g según el algoritmo eliminar segmentos de puntos definido en RFC 3986. Esta normalización se produce antes de comprobar la caché o de reenviar la solicitud al origen.
  • Las solicitudes no se normalizan con codificación de porcentaje. Por ejemplo, una URL con una barra codificada con porcentaje (%2F) no se decodifica en la forma sin codificar.

Las URLs siguen distinguiendo entre mayúsculas y minúsculas y no se normalizan. Muchas URLs contienen codificaciones base64 que distinguen entre mayúsculas y minúsculas, incluidas las URLs con tokens de solicitud firmada.

Reescritura y redirección

En las siguientes secciones se ofrecen ejemplos de cómo reformular solicitudes y configurar redirecciones.

Reescribir las URLs de las solicitudes

Media CDN admite la reescritura de hosts y rutas. Las reescrituras cambian la URL enviada al origen y te permiten modificar los hosts y las rutas según sea necesario. Las reescrituras de host y ruta se realizan a nivel de ruta, lo que te permite definir qué solicitudes específicas se reescriben en función de cualquier matcher, como la ruta, el parámetro de consulta y el encabezado de la solicitud.

Para obtener más información, consulta la especificación de la API de RouteAction.UrlRewrite.

A continuación, se indican tres formas de reformular una solicitud:

Campo Descripción
urlRewrite.pathPrefixRewrite

Reescribe la ruta y quita el prefijo especificado en el prefixMatch que coincida con la solicitud.

Solo se puede especificar un elemento pathPrefixRewrite o pathTemplateRewrite en una regla de ruta.

urlRewrite.pathTemplateRewrite

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

Solo se puede especificar un elemento pathPrefixRewrite o pathTemplateRewrite en una regla de ruta.

urlRewrite.hostRewrite Reescribe 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 la URL de la solicitud enviada por el cliente.
  • La reescritura se produce después de la validación de la solicitud firmada y de la coincidencia de rutas. Las rutas no se vuelven a asociar con otra regla de coincidencia.

Ejemplo: Quitar un prefijo de ruta

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), 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 sustituyendo todo el prefijo de ruta que coincida en matchRules[].prefixMatch por el valor de pathPrefixRewrite.

Para reescribir un nombre de host (por ejemplo, reescribir cdn.example.com como my-bucket.s3.us-west-2.amazonaws.com), puede configurar lo siguiente:

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/videos/"
      routeAction:
        urlRewrite:
          hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"

En este caso, la URL de solicitud de origen cambiaría de cdn.example.com/videos/* a my-bucket.s3.us-west-2.amazonaws.com/videos/*. También puedes combinar la reescritura de host y de ruta en una sola ruta.

Ejemplo: Usar variables para reescribir URLs

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

Redirigir solicitudes

Media CDN admite tres tipos de redirecciones:

  • Redirecciones de host, que redirigen solo el host (dominio) y mantienen la ruta y los parámetros de consulta sin cambios.
  • Redirecciones de ruta, que sustituyen la ruta por completo.
  • Redirecciones de prefijo de ruta, que solo sustituyen el prefijo coincidente.

Las redirecciones se definen de forma predeterminada en HTTP 301 (Moved Permanently), pero se pueden configurar para que devuelvan códigos de estado de redirección diferentes por ruta.

La siguiente configuración es un ejemplo de redirección basada en prefijos, en la que se redirige a los usuarios que visitan https://cdn.example.com/on-demand/* a https://cdn.example.com/streaming/*.

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      matchRules:
      - prefixMatch: "/on-demand/"
      urlRedirect:
        # The prefix matched in matchRules.prefixMatch is replaced
        # by this value
        prefixRedirect: "/streaming/"
        redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307

En este ejemplo también se cambia la redirección a una redirección temporal, lo que impide que los clientes (como los navegadores) la almacenen en caché. Esto puede ser útil si tienes previsto cambiarlo en un futuro próximo.

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

Redirigir código de respuesta Código de estado HTTP
MOVED_PERMANENTLY_DEFAULT HTTP 301 (Movido permanentemente)
FOUND HTTP 302 (Found)
SEE_OTHER HTTP 303 (Ver otra ubicación)
TEMPORARY_REDIRECT HTTP 307 (Redirección temporal)
PERMANENT_REDIRECT HTTP 308 (Redirección permanente)

Notas:

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

Para obtener más información, consulta la especificación de la API de RouteRule.UrlRedirect.

Redirigir todas las solicitudes a HTTPS

Para redirigir todas las solicitudes a HTTPS (en lugar de HTTP), puedes configurar cada uno de tus servicios para que redirija automáticamente todas las solicitudes de los clientes a HTTPS. Los clientes que se conectan a través de HTTP reciben una respuesta HTTP 301 (Permanent Redirect) con el encabezado Location definido en la misma URL, pero con "https://" en lugar de "http://".

gcloud

gcloud edge-cache services update MY_SERVICE \
    --require-tls
Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

El comando devuelve una descripción de tu servicio, con requireTls ahora definido como true.

  name: MY_SERVICE
  requireTls: true
HTTP.

También puede definir el encabezado Strict-Transport-Security como encabezado de respuesta para indicar a los clientes que siempre se conecten directamente a través de HTTPS.

Usar back-ends de almacenamiento de terceros

Media CDN admite la conexión a endpoints HTTP accesibles públicamente fuera de Google Cloud, incluidos los segmentos de almacenamiento de AWS S3, Azure Blob Storage y otros proveedores de almacenamiento. Esto puede ser útil si tienes una arquitectura multicloud o aún no has migrado datos a Cloud Storage con el Servicio de transferencia de Storage.

Configuración de origen mínima que configura un cubo alojado virtualmente en AWS S3:

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

Si no usas un nombre de contenedor que coincida con los nombres de host configurados para tus recursos EdgeCacheService, también debes configurar una reescritura de host para las rutas asociadas a este origen (u orígenes). De lo contrario, se usa el encabezado Host definido por la solicitud del cliente al obtener datos del origen.

Por ejemplo, para asignar todas las solicitudes con el prefijo de ruta /legacy/ a tu cubo externo, puedes configurar tanto un hostRewrite como 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 define 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)

Uso compartido de recursos entre dominios (CORS) es un enfoque centrado en el navegador para hacer solicitudes entre dominios de forma segura. Las políticas de CORS te permiten definir automáticamente encabezados de CORS, como Access-Control-Allow-Origins, en función de 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 definir encabezados CORS comunes en las respuestas, como Access-Control-Allow-Origin, Access-Control-Max-Age y Access-Control-Allow-Headers. Estos encabezados le permiten hacer llamadas entre orígenes a sus servicios de CDN multimedia que pueden estar alojados en un dominio (origen) diferente del frontend de su sitio web y pueden evitar solicitudes entre orígenes que no permita 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 que tu aplicación frontend haga solicitudes a api.example.com para obtener la siguiente lista de reproducción o actualizar una lista de contenido relacionado. Del mismo modo, es posible que player.example.com tenga que ponerse en contacto con cdn.example.com para obtener listas de reproducción y segmentos de vídeo. cdn.example.com debe indicar que no hay ningún problema y que player.example.com es un allowed origin, así como cualquier otra regla (encabezados permitidos, si se pueden incluir cookies, etc.).

Por ejemplo, si quieres permitir stream.example.com como origen y un encabezado X-Client-ID en las solicitudes CORS, puedes configurar un corsPolicy en una ruta, como se indica a continuación:

corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders:
["X-Client-ID"]

Un corsPolicy se configura en routing.pathMatchers[].routeRules[].routeAction.corsPolicy dentro de un EdgeCacheService. Cada routeRule puede definir un corsPolicy diferente según sea necesario o no definir ninguno.

Si define un valor de corsPolicy y también establece un encabezado de respuesta personalizado mediante 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 define encabezados HTTP y tiene un valor de corsPolicy definido, se usarán los valores de corsPolicy. Los valores no se contraen ni se combinan para evitar enviar valores de encabezado no válidos a un cliente o para no definir una política más permisiva de lo previsto.

El {origin_request_header} especial se rellena con el encabezado HTTP Origin de la solicitud del cliente. Se puede definir como un valor de encabezado de respuesta personalizado en una ruta para el encabezado Access-Control-Allow-Origin.

Para obtener más información, consulta la especificación de la API de RouteAction.CORSPolicy.

Campos de la política de CORS

En la siguiente tabla se describen los campos que contiene una política de CORS.

Campo Descripción Ejemplo
allowOrigins

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

Por ejemplo, si tu contenido de vídeo se sirve desde https://video.example.com, pero tu portal visible para los usuarios se sirve desde https://stream.example.com, deberías añadir https://stream.example.com como origen permitido.

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

Define el encabezado de respuesta Access-Control-Max-Age, que especifica el tiempo (en segundos) que un cliente de navegador debe almacenar en caché la respuesta a una solicitud preparatoria de CORS.

Algunos navegadores limitan este valor a 2 horas o menos, aunque se especifique el valor máximo (86.400 s).

Access-Control-Max-Age: 7200
allowMethods

Define 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 los métodos GET, HEAD y OPTIONS. Para configurar la compatibilidad con otros métodos, consulta Métodos de ruta.

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

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

A menudo, los reproductores de vídeo lo requieren para acceder a algunos encabezados de respuesta del contenido de vídeo cuando se solicita entre orígenes.

Access-Control-Allow-Headers: Content-Type, If-Modified-Since, Range, User-Agent
exposeHeaders

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

Los reproductores de vídeo suelen necesitarlo para acceder a encabezados de respuesta específicos del contenido de vídeo al solicitar contenido entre orígenes.

Access-Control-Expose-Headers: Date, Cache-Status, Content-Type, Content-Length
allowCredentials

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

Este encabezado se omite si se define como "false".

Access-Control-Allow-Credentials: true
disabled Inhabilita el corsPolicy sin eliminarlo. Las solicitudes de comprobación previa al vuelo OPTIONS se envían al origen a través de un proxy. N/A

Ejemplo de corsPolicy

En el siguiente ejemplo de configuración se muestra una configuración corsPolicy básica:

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"

Solucionar problemas de enrutamiento

Si algunas solicitudes no devuelven resultados coincidentes o devuelven errores, comprueba lo siguiente:

  • Una ruta debe tener un matchRule con exactamente uno de los valores prefixMatch, fullPathMatch o pathTemplateMatch definidos. La API devuelve un error si no incluye 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 mayor que las rutas más cortas y generales.
  • De forma predeterminada, solo se admiten las solicitudes GET, HEAD y OPTIONS. Para configurar la compatibilidad con otros métodos, consulta Métodos de ruta. Los métodos que no están habilitados para una ruta concreta se rechazan con un error HTTP 405 (Method Not Allowed).
  • Las solicitudes HTTP GET con un cuerpo o cualquier solicitud con tráilers se rechazan con un error HTTP 400, porque no se permiten cuerpos de solicitud en las solicitudes GET.
  • La coincidencia de parámetros de consulta y encabezados es lógica "AND": la solicitud debe coincidir con todas las claves de parámetros de consulta o de encabezados (y los valores, si se especifican) para coincidir con la ruta determinada.

Siguientes pasos