Media CDN te permite especificar encabezados de solicitud y respuesta personalizados.
Los encabezados personalizados te permiten hacer lo siguiente:
- Devuelve datos geográficos sobre el cliente, como el país, la región o la 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ó.
- Quita, reemplaza o adjunta a los encabezados de solicitud y respuesta.
También puedes usar encabezados para enrutar solicitudes a diferentes orígenes. Si necesitas configurar varios orígenes Encabezados de uso compartido de recursos (CORS), configura un CORS política para cada ruta.
Cómo establecer encabezados personalizados
Los encabezados se establecen en cada ruta, lo que te permite agregar y quitar encabezados para contenido diferente, como manifiestos o segmentos de video.
De forma predeterminada, los valores de encabezado agregados se separan por comas y se adjuntan a la respuesta. o solicitudes con los mismos nombres de campo.
Para reemplazar los valores existentes, establece replace
en true
.
En el siguiente ejemplo de .routing.pathMatchers[].routeRules[].headerAction
, se muestra
encabezados agregados y quitados en un recurso EdgeCacheService
:
gcloud edge-cache services describe prod-media-service
routeRules: - priority: 1 description: "video routes" matchRules: - prefixMatch: "/video/" headerAction: responseHeadersToAdd: # Return the country (or region) associated with the client's IP address. - headerName: "client-geo" headerValue: "{client_region}" replace: true 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 realizan las acciones siguientes:
- Agrega un encabezado
client-geo
personalizado a la respuesta mediante el elemento Variable{client_region}
, que muestra el país (o la región) asociado con la dirección IP del cliente. - Agrega un encabezado
x-downstream-cdn
personalizado a la solicitud mediante un elemento una cadena vacía. - Quita dos encabezados internos.
Variables de encabezado dinámico
Los encabezados personalizados pueden contener una o más variables dinámicas.
Los encabezados de solicitud que forman parte de la política de claves de caché (cacheKeyPolicy.includedHeaderNames
) pueden contener una o más variables personalizadas. Encabezados de solicitud que contienen
las variables dinámicas no pueden ser parte de la clave de caché.
Variable | Descripción | Compatible con encabezados de solicitud | Compatible con encabezados de solicitud en una clave de caché | Compatible con los encabezados de respuesta |
---|---|---|---|---|
cdn_cache_status |
Una lista de ubicaciones separadas por comas (código IATA del aeropuerto más cercano) y estados de cada nodo de la caché en la ruta de solicitud/respuesta, donde el valor de la derecha representa la caché más cercana al usuario. | ✔ | ||
client_city |
Es el nombre de la ciudad de donde proviene la solicitud, por ejemplo,
Mountain View para Mountain View, California. No hay
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 desde la que se realizó la solicitud
se originó, por ejemplo, 37.386051,-122.083851
por una solicitud de Mountain View. |
✔ | ✔ | |
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 |
La subdivisión del país, por ejemplo, la provincia o el estado
asociada con la dirección IP del cliente. Esta es una subdivisión CLDR de Unicode
como USCA o CAON . Estos códigos Unicode
se derivan de las subdivisiones definidas por el
ISO-3166-2
estándar. |
✔ | ✔ | ✔ |
client_rtt_msec |
Es el tiempo estimado de transmisión de ida y vuelta entre la CDN y el cliente HTTP(S), en milisegundos. Este es el tiempo de ida y vuelta suavizado (SRTT) medido por la pila de TCP de la CDN, por RFC 2988. | ✔ | ✔ | |
device_request_type |
El tipo de dispositivo que usa el cliente. Estos son los valores
válidos: DESKTOP , MOBILE ,
TABLET , SMART_TV ,
GAME_CONSOLE , WEARABLE y
UNDETERMINED . |
✔ | ✔ | |
original_request_id |
El identificador único asignado a la solicitud que originalmente
generó esta respuesta. Se propaga solo si es diferente de request_id para las respuestas almacenadas en caché. |
✔ | ||
origin_name |
El recurso EdgeCacheOrigin desde el que se originó la respuesta
se le envió un proxy. |
✔ | ||
origin_request_header |
Refleja el valor del encabezado Origen en la solicitud de origen cruzado. Casos de uso de uso compartido de recursos (CORS). | ✔ | ||
proxy_status |
Una lista de proxies HTTP intermediarios en la ruta de respuesta. El valor
se define por
RFC 9209
Un recurso EdgeCacheService se representa como
Google-Edge-Cache Si la respuesta se recuperó del origen,
un EdgeCacheOrigin
recurso se representa con Google-Edge-Cache-Origin . |
✔ | ||
tls_sni_hostname |
La indicación del nombre del servidor (como se define en RFC 6066), si que proporciona el cliente durante el protocolo de enlace TLS o QUIC. El nombre de host es y se convierte a minúscula y se quita cualquier punto final. | ✔ | ✔ | |
tls_version |
La versión de TLS negociada entre el cliente y el balanceador de cargas
durante el protocolo de enlace SSL. Entre los valores posibles, se incluyen 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 |
El conjunto de algoritmos de cifrado negociado durante el protocolo de enlace TLS. El valor se define
por la IANA
TLS Cifer Suite Registry, por ejemplo,
TLS_RSA_WITH_AES_128_GCM_SHA256 Este valor está vacío para QUIC y las conexiones de cliente no encriptadas. |
✔ | ✔ | |
user_agent_family |
La familia del navegador que usa el cliente. Estos son los estados válidos
valores: APPLE , APPLEWEBKIT ,
BLACKBERRY , DOCOMO y GECKO
GOOGLE , KHTML y KOREAN ,
MICROSOFT , MSIE , NOKIA ,
NETFRONT , OBIGO , OPENWAVE
OPERA , OTHER , POLARIS
TELECA , SEMC , SMIT y
USER_DEFINED . |
✔ | ✔ |
Las siguientes consideraciones se aplican a las variables personalizadas:
Los encabezados de solicitud y respuesta existentes se conservan, excepto por el siguientes, que se eliminaron:
X-User-IP
- Cualquier encabezado con
X-Google
oX-GFE
Las claves y los valores de encabezado deben cumplir con el RFC 7230, con No se permiten los formularios obsoletos.
Todas las claves de encabezado están en minúsculas (según 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, comoSet-Cookie
, nunca se combinan.Algunos encabezados se agregan o se les agregan valores. Media CDN siempre agrega o modifica ciertos encabezados, como
Via
yX-Forwarded-For
.Media CDN expande cualquier encabezado de respuesta con una variable compatible, incluso si la establece el cliente o el origen. Esto permite Estableces encabezados dinámicos para el origen o el cliente (como un reproductor de video). de Google, además de configurar encabezados personalizados. Media CDN no expande las variables en la ruta de la solicitud.
Por ejemplo, según las reglas descritas anteriormente, los encabezados
X-Goog-
yX-Amz-
se conservan y se convierten a minúsculas.
Valores de estado de la caché
La variable de encabezado {cdn_cache_status}
puede mostrar varios valores
correspondiente al nivel de caché que entregó la respuesta. Ten en cuenta
siguientes lineamientos para interpretar la variable de encabezado {cdn_cache_status}
:
- Si el encabezado contiene
hit
, se recuperó el contenido solicitado. de la caché. - Si el encabezado contiene
miss
, significa que el contenido solicitado no se encontrados en un nodo de caché y que debían recuperarse de un nodo upstream. - Si el encabezado contiene
fetch
, significa que el contenido solicitado se recuperados del origen. Si el encabezado contiene
uncacheable
, significa que el contenido solicitado se no se puede almacenar en caché para algunos o todos los componentes de Google Cloud.- Si el encabezado también contiene
hit
omiss
, el valor algunos componentes de la caché consideraron que el contenido solicitado no se puede almacenar en caché y otros pueden almacenarlo en caché. - Si el encabezado no contiene también
hit
omiss
, el contenido solicitado se consideró que no se puede almacenar en caché por todos los componentes de almacenamiento en caché, y se recuperan todas las solicitudes de este contenido desde el origen. Para asegurarte de que tu contenido se almacene en caché de forma adecuada, revisa los requisitos de origen de Media CDN.
- Si el encabezado también contiene
Encabezados predeterminados
Media CDN agrega los siguientes encabezados de solicitud y respuesta a las solicitudes de origen y las respuestas del cliente, respectivamente.
Encabezado | Descripción | Solicitud | Respuesta |
---|---|---|---|
x-request-id |
Es 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 |
Devuelve la antigüedad del objeto almacenado en caché (cantidad de segundos que ha estado en la caché). La edad generalmente se calcula en función del momento en que la al principio se almacenó en caché en una ubicación de caché de cola larga (escudo). Las respuestas sin un encabezado |
✔ | |
via |
Identifica a Google como el proxy intermedio. Se establece como |
✔ | ✔ |
server |
Se estableció como Google-Edge-Cache . |
✔ | |
cdn-loop |
Identifica bucles, por ejemplo, donde el host de origen es el que el host para el usuario (perímetro). Se adjunta un token de |
✔ | |
forwarded |
La versión estructurada del encabezado Estos encabezados te permiten identificar la dirección IP de la conexión
cliente cuando un proxy (o proxies) esté en la ruta. Por ejemplo, si un
cliente con la dirección IP a la que se conecta
En el caso de varios proxies del cliente, el cliente que se conectó a Media CDN es la última dirección anexada al encabezado. valor. |
✔ | |
x-forwarded-for |
La versión no estructurada y estándar de facto del
Encabezado Ambos encabezados se envían en una solicitud para admitir orígenes heredados que podrían
no debes tener en cuenta el encabezado |
✔ |
Las claves de encabezado están en minúscula para los encabezados de solicitud y respuesta porque las claves no distinguen mayúsculas de minúsculas.
Se pueden agregar otros encabezados, como la ubicación del punto de presencia (PoP) perimetral y el estado de la caché (como hit
y miss
), con las variables de encabezado dinámico.