Define encabezados personalizados

Media CDN te permite especificar encabezados de solicitud y respuesta personalizados. Los encabezados de solicitud personalizados admiten valores estáticos, mientras que los encabezados de respuesta personalizados admiten valores estáticos y dinámicos.

Los encabezados personalizados te permiten hacer lo siguiente:

  • Mostrar datos geográficos sobre el cliente, como país, región o ciudad, que puedes usar para mostrar contenido localizado.
  • Determinar si una respuesta se entregó desde la caché (en su totalidad o en parte) y desde qué ubicación de caché se entregó.
  • Quitar o reemplazar los encabezados de solicitud y respuesta.

También puedes usar encabezados para enrutar solicitudes a diferentes orígenes, como se describe en la documentación de enrutamiento avanzado. Si necesitas configurar los encabezados de uso compartido de recursos entre dominios (CORS), configura una política de CORS para cada ruta.

Establece encabezados personalizados

Los encabezados se configuran en cada ruta, lo que te permite agregar y quitar encabezados de distintos contenidos, como manifiestos o segmentos de video.

De forma predeterminada, los valores de encabezado agregados se agregan a los encabezados de la solicitud o respuesta con los mismos nombres de campo. Los valores agregados se separan mediante comas.

Para reemplazar los valores existentes, establece replace en true.

En el siguiente ejemplo de .routing.pathMatchers[].routeRules[].headerAction, se muestran los encabezados que se agregaron y quitaron en un EdgeCacheService:

gcloud edge-cache services describe prod-media-service
routeRules:
- priority: 1
  description: "video routes"
  matchRules:
  - prefixMatch: "/video/"
  headerAction:
    responseHeadersToAdd:
      # Return the IATA (airport) code(s) nearest the cache node(s) that served
      # the response
      - headerName: "cache-id"
        headerValue: "{cdn_cache_id}"
        replace: true
      # Return how the response was served - for example, "MISS, HIT"
      - headerName: "x-cache-status"
        headerValue: "{cdn_cache_status}"
    requestHeadersToAdd:
      # Inform the upstream origin server the request is from Media CDN
      - headerName: "x-downstream-cdn"
        headerValue: "Media CDN"
    responseHeadersToRemove:
      - headerName: "X-User-ID"
      - headerName: "X-Other-Internal-Header"

En este ejemplo, se dan las siguientes situaciones:

  • Agrega un encabezado Cache-ID personalizado a la respuesta mediante la variable {cdn_cache_id}, que muestra el ID de la caché (o los ID, si se usa un relleno en niveles) que se usa para entregar la solicitud.
  • Agrega un encabezado x-downstream-cdn personalizado a la solicitud con una string estática.
  • Quita dos encabezados internos.

Variables de encabezado dinámico

Los encabezados de respuesta admiten variables personalizadas, idénticas a las compatibles con Cloud CDN y el balanceo de cargas de HTTP(S).

La lista de variables compatibles se define de la siguiente manera:

Variable Descripción
cdn_cache_id Código de ubicación e ID de la instancia de caché que se usa para entregar la solicitud. Este es el mismo valor propagado en el campo jsonPayload.cacheId de los registros de solicitud de Cloud CDN en Logging.
cdn_cache_status Estado actual de la caché. Los valores reflejan el estado de la respuesta almacenada en caché y el nivel de caché desde el que se entregó (si corresponde).
origin_request_header Refleja el valor del encabezado de origen en la solicitud de casos de uso de uso compartido de recursos entre dominios (CORS).
client_rtt_msec Tiempo estimado de transmisión de ida y vuelta entre el balanceador de cargas y el cliente HTTP(S), en milisegundos. Este es el parámetro de tiempo de ida y vuelta suavizado (SRTT) medido por la pila TCP del balanceador de cargas, según RFC 2988.
client_region El país (o región) asociado a la dirección IP del cliente. Este es un código regional CLDR de Unicode, como US o FR. (Para la mayoría de los países, estos códigos corresponden directamente a los códigos ISO-3166-2).
client_region_subdivision Subdivisión: (por ejemplo, una provincia o un estado) del país asociado a la dirección IP del cliente. Este es un ID de subdivisión CLDR de Unicode, como USCA o CAON. (Estos códigos Unicode se derivan de las subdivisiones definidas por el estándar ISO-3166-2).
client_city Nombre de la ciudad desde la que se originó la solicitud, por ejemplo, Mountain View para Mountain View, California. No hay una lista canónica de valores válidos para esta variable. Los nombres de las ciudades pueden contener letras, números, espacios y los siguientes caracteres de US-ASCII: !#$%&'*+-.^_`|~.
client_city_lat_long La latitud y longitud de la ciudad en la que se originó la solicitud, por ejemplo, 37.386051,-122.083851 para una solicitud de Mountain View.
tls_sni_hostname Indicación del nombre del servidor (como se define en RFC 6066), si el cliente la proporciona durante el protocolo de enlace de TLS o QUIC. El nombre de host se pasa a minúsculas y se quita cualquier punto final.
tls_version Versión de TLS negociada entre el cliente y el balanceador de cargas durante el protocolo de enlace SSL. Los valores posibles son TLSv1, TLSv1.1, TLSv1.2 y TLSv1.3. Si el cliente se conecta con QUIC en lugar de TLS, el valor es QUIC.
tls_cipher_suite Conjunto de cifrado negociado durante el protocolo de enlace TLS. El valor son cuatro dígitos hexadecimales definidos por el conjunto de algoritmos de cifrado TLS de IANA, por ejemplo, 009C para TLS_RSA_WITH_AES_128_GCM_SHA256. Este valor está vacío para QUIC y las conexiones de cliente no encriptadas.

Se conservan los encabezados de solicitud y respuesta existentes, excepto los siguientes, que se quitan:

  • X-User-IP
  • Cualquier encabezado con X-Google o X-GFE

Además, tenga en cuenta lo siguiente:

  • Las claves y los valores de encabezado deben cumplir con RFC 7230, y los formularios obsoletos no están permitidos.
  • Todas las claves de encabezado están en minúsculas (por HTTP/2).
  • Algunos encabezados se combinan. Cuando hay varias instancias de la misma clave de encabezado (por ejemplo, Via), el balanceador de cargas combina sus valores en una lista separada por comas para una sola clave de encabezado. Solo se agrupan los encabezados cuyos valores se pueden representar como una lista separada por comas. Otros encabezados, como Set-Cookie, nunca se combinan.
  • Algunos encabezados se agregan o se les agregan valores. Los balanceadores de cargas de HTTP(S) externos siempre agregan o modifican ciertos encabezados, como Via y X-Forwarded-For.
  • Media CDN expande cualquier encabezado de respuesta con una variable compatible, incluso si la configura el cliente o el origen. Esto te permite configurar encabezados dinámicos de tu cliente (como un reproductor de video) o de infraestructura de origen, además de configurar encabezados personalizados. Media CDN no expande las variables en la ruta de la solicitud.

Valores de estado de caché

La variable del encabezado {cdn_cache_status} puede mostrar varios valores correspondientes al nivel de caché que entregó la respuesta.

Valor Descripción
HIT La respuesta almacenada en caché se entregó por completo desde la caché.
MISS La respuesta no estaba en la caché.
PARTIAL La respuesta se entregó de forma parcial desde la caché.

En el caso de objetos grandes (2 MB o más), esto significa que solo estaban disponibles los bytes parciales en la caché y que se realizó una solicitud de rango HTTP para llenar el resto de la respuesta solicitada.

REVALIDATED La respuesta estaba presente en la caché, pero revalidó el origen antes de que se entregara.
BYPASSED Se omitió la caché. Esto ocurre cuando el valor cdnPolicy.cacheMode de una ruta determinada se establece en BYPASS_CACHE, por ejemplo, cuando se depura.
UNCACHEABLE La respuesta no se pudo entregar desde la caché y se recuperó del origen directamente. Esto puede ocurrir si la respuesta no incluye directivas de caché válidas, era demasiado grande para almacenar en caché o no era un tipo de contenido que se puede almacenar en caché, según cdnPolicy.cacheMode.

El campo cache_details en el registro de solicitud correspondiente contiene el motivo.

Cada nivel de caché en la ruta de respuesta (si corresponde) se agrega al valor del encabezado.

Ejemplos:

  • Si una respuesta de caché no estaba disponible en la caché más cercana al usuario, pero la entregó el siguiente nivel, el cdn_cache_status es HIT, MISS.
  • Si la respuesta de caché no estaba disponible en los dos primeros niveles de caché, y solo una parte parcial de la respuesta estaba disponible en la caché, el cdn_cache_status es PARTIAL, MISS, MISS.

Para las solicitudes y respuestas en las que se aplican BYPASSED y UNCACHEABLE, solo verás un valor en cdn_cache_status, ya que estos valores se aplican a todos los niveles de caché.

Encabezados predeterminados

Media CDN agrega los siguientes encabezados de solicitud y respuesta a las solicitudes de origen y respuestas del cliente, respectivamente:

Encabezado Detalles Solicitud Respuesta
x-request-id Un identificador único para la solicitud determinada. Este valor también se agrega al registro de solicitudes como jsonPayload.requestId, lo que te permite correlacionar una solicitud o respuesta del cliente con una entrada de registro.
age Muestra la antigüedad del objeto almacenado en caché (cantidad de segundos que ha estado en la caché). Por lo general, la antigüedad se calcula en función del momento en que el objeto se almacenó en caché en una ubicación de caché de cola larga (escudo).

Las respuestas sin un encabezado Age no se entregan desde la caché.

via Identifica a Google como el proxy intermedio.

Configurado como 1.1 google y no se puede cambiar.

server Se establece como Google-Edge-Cache.
cdn-loop Identifica “bucles”, por ejemplo, en los que el host de origen es el mismo que el host (borde) para el usuario.

Se agrega un token de google al encabezado según RFC 8586. El token no se puede cambiar.

forwarded La versión estructurada del encabezado x-forwarded-for. El encabezado forwarded se define en RFC 7239.

Estos encabezados te permiten identificar la dirección IP del cliente que se conecta cuando hay un proxy (o proxies) en la ruta. Por ejemplo, si un cliente con la dirección IP 192.0.2.60 se conecta a Media CDN a través de HTTPS, el encabezado forwarded se propaga de la siguiente manera:

forwarded: [for=192.0.2.60;proto=https]

En el caso de varios proxies del cliente, el cliente que se conectó a Media CDN es la última dirección que se agregó en el valor del encabezado.
x-forwarded-for La versión estándar no estructurada y de hecho del encabezado forwarded. Por lo general, los valores están separados por comas.

Ambos encabezados se envían en una solicitud para admitir orígenes heredados que podrían no conocer el encabezado forwarded.

Las claves de encabezado están en minúsculas para los encabezados de solicitud y respuesta, ya que las claves de encabezado no distinguen mayúsculas de minúsculas.

Se pueden agregar otros encabezados, incluidos la ubicación POP perimetral y el estado de la caché (como HIT y MISS), a través de variables de encabezado dinámico.