O Media CDN permite especificar cabeçalhos personalizados de solicitação e resposta.
Os cabeçalhos personalizados permitem o seguinte:
- Retorne dados geográficos sobre o cliente, como país, região ou cidade, que podem ser usados para mostrar conteúdo localizado.
- Determine se uma resposta foi veiculada a partir do cache (total ou parcialmente) e em qual local do cache ela foi veiculada.
- Remova, substitua ou anexe aos cabeçalhos de solicitação e resposta.
Também é possível usar cabeçalhos para encaminhar solicitações para origens diferentes. Se você precisar configurar cabeçalhos de compartilhamento de recursos entre origens (CORS, na sigla em inglês), configure uma política de CORS para cada rota.
Definir cabeçalhos personalizados
Os cabeçalhos são definidos em cada rota, o que permite adicionar e remover cabeçalhos para conteúdos diferentes, como manifestos ou segmentos de vídeo.
Por padrão, os valores de cabeçalho adicionados são separados por vírgulas e anexados aos cabeçalhos de resposta ou solicitação com os mesmos nomes de campos.
Para substituir os valores atuais, defina replace
como true
.
O exemplo de .routing.pathMatchers[].routeRules[].headerAction
a seguir mostra
os cabeçalhos adicionados e removidos em um 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"
Este exemplo faz o seguinte:
- Adiciona um cabeçalho
client-geo
personalizado à resposta usando a variável{client_region}
, que retorna o país (ou região) associado ao endereço IP do cliente. - Adiciona um cabeçalho
x-downstream-cdn
personalizado à solicitação usando uma string estática. - Remove dois cabeçalhos internos.
Variáveis de cabeçalho dinâmicas
Os cabeçalhos personalizados podem conter uma ou mais variáveis dinâmicas.
Os cabeçalhos de solicitação que fazem parte da política de chave de cache (cacheKeyPolicy.includedHeaderNames
)
podem conter uma ou mais variáveis personalizadas. Os cabeçalhos de solicitação que contêm outras
variáveis dinâmicas não podem fazer parte da chave de cache.
Variável | Descrição | Compatível com cabeçalhos de solicitação | Compatível com cabeçalhos de solicitação em uma chave de cache. | Compatível com cabeçalhos de resposta |
---|---|---|---|---|
cdn_cache_status |
Uma lista separada por vírgulas dos locais (código IATA do aeroporto mais próximo) e status de cada nó de cache no caminho de solicitação/resposta, em que o valor mais à direita representa o cache mais próximo do usuário. | ✔ | ||
client_city |
O nome da cidade de origem da solicitação. Por exemplo, Mountain View para Mountain View, Califórnia. Não há
uma lista canônica de valores válidos para essa variável. Os nomes das cidades podem conter letras, números, espaços, caracteres US-ASCII e os seguintes caracteres: !#$%&'*+-.^_`|~ . |
✔ | ✔ | |
client_city_lat_long |
A latitude e a longitude da cidade de origem da solicitação, por exemplo, 37.386051,-122.083851 para uma solicitação de Mountain View. |
✔ | ✔ | |
client_region |
O país (ou região) associado ao endereço IP do cliente. Este é um código regional Unicode CLDR, como US ou FR .
Na maioria dos países, esses códigos correspondem diretamente a códigos ISO-3166-2. |
✔ | ✔ | ✔ |
client_region_subdivision |
A subdivisão (por exemplo, a província ou o estado) do país
associada ao endereço IP do cliente. Este é um ID de subdivisão Unicode CLDR, como USCA ou CAON . Esses códigos Unicode
são derivados das subdivisões definidas pelo
padrão
ISO-3166-2. |
✔ | ✔ | ✔ |
client_rtt_msec |
Tempo estimado de retorno da transmissão entre a CDN e o cliente HTTP(S), em milissegundos. É o parâmetro de tempo de retorno suavizado (SRTT, na sigla em inglês) medido pela pilha TCP da CDN, de acordo com a RFC 2988 (link em inglês). | ✔ | ✔ | |
device_request_type |
O tipo de dispositivo que o cliente está usando. Estes são os valores válidos: DESKTOP , MOBILE , TABLET , SMART_TV , GAME_CONSOLE , WEARABLE e UNDETERMINED . |
✔ | ✔ | |
original_request_id |
O identificador exclusivo atribuído à solicitação que gerou essa resposta originalmente. Preenchido apenas se for diferente de
request_id para respostas armazenadas em cache. |
✔ | ||
origin_name |
O recurso EdgeCacheOrigin do qual a resposta foi enviada por proxy. |
✔ | ||
origin_request_header |
Reflete o valor do cabeçalho Origin na solicitação de casos de uso de Compartilhamento de recursos entre origens (CORS). | ✔ | ||
proxy_status |
Uma lista de proxies HTTP intermediários no caminho de resposta. O valor
é definido pela
RFC 9209 (link em inglês).
Um recurso EdgeCacheService é representado por
Google-Edge-Cache . Se a resposta foi buscada na origem, um recurso EdgeCacheOrigin é representado por Google-Edge-Cache-Origin . |
✔ | ||
tls_sni_hostname |
Indicação do nome do servidor (conforme definido na RFC 6066, link em inglês), se fornecida pelo cliente durante o handshake de TLS ou QUIC. O nome do host é convertido em letras minúsculas, e qualquer ponto à direita é removido. | ✔ | ✔ | |
tls_version |
A versão de TLS negociada entre o cliente e o balanceador de carga durante o handshake SSL. Os valores possíveis incluem TLSv1 , TLSv1.1 , TLSv1.2 e TLSv1.3 . Se o cliente se conectar usando QUIC em vez de
TLS, o valor será QUIC. |
✔ | ✔ | |
tls_cipher_suite |
O pacote de criptografia negociado durante o handshake de TLS. O valor é definido pelo Registro do pacote de criptografia TLS da IANA (em inglês), por exemplo, TLS_RSA_WITH_AES_128_GCM_SHA256 . Este valor fica vazio
para conexões de cliente QUIC e não criptografadas. |
✔ | ✔ | |
user_agent_family |
A família de navegadores que o cliente está usando. Estes são os valores válidos: APPLE , APPLEWEBKIT , BLACKBERRY , DOCOMO , GECKO , GOOGLE , KHTML , KOREAN , MICROSOFT , MSIE , NOKIA , NETFRONT , OBIGO , OPENWAVE , OPERA , OTHER , POLARIS , TELECA , SEMC , SMIT e USER_DEFINED . |
✔ | ✔ |
As seguintes considerações se aplicam às variáveis personalizadas:
Os cabeçalhos de solicitação e resposta atuais são preservados, exceto os seguintes, que são removidos:
X-User-IP
- Todos os cabeçalhos com
X-Google
ouX-GFE
As chaves e os valores de cabeçalho precisam estar em conformidade com a RFC 7230 (link em inglês), sem formulários obsoletos.
Todas as chaves de cabeçalho estão em letras minúsculas (por HTTP/2).
Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo,
Via
), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, comoSet-Cookie
, nunca são agrupados.Alguns cabeçalhos são adicionados ou têm valores anexados a eles. O Media CDN sempre adiciona ou modifica determinados cabeçalhos, como
Via
eX-Forwarded-For
.O Media CDN expande todos os cabeçalhos de resposta com uma variável compatível, mesmo que definida pelo cliente ou pela origem. Isso permite definir cabeçalhos dinâmicos do seu cliente (como um player de vídeo) ou da infraestrutura de origem, além de configurar cabeçalhos personalizados. O Media CDN não expande variáveis no caminho da solicitação.
Por exemplo, de acordo com as regras descritas anteriormente, os cabeçalhos
X-Goog-
eX-Amz-
são preservados e estão em letras minúsculas.
Valores de status do cache
A variável de cabeçalho {cdn_cache_status}
pode retornar vários valores
correspondentes ao nível de cache que veiculou a resposta. Considere as
diretrizes a seguir para interpretar a variável de cabeçalho {cdn_cache_status}
:
- Se o cabeçalho contiver
hit
, o conteúdo solicitado foi recuperado do cache. - Se o cabeçalho contiver
miss
, isso significa que o conteúdo solicitado não foi encontrado em um nó de cache e teve que ser recuperado de um nó upstream. - Se o cabeçalho contiver
fetch
, isso significa que o conteúdo solicitado foi recuperado da origem. Se o cabeçalho contiver
uncacheable
, isso significa que o conteúdo solicitado foi considerado não armazenável em cache por alguns ou todos os componentes da infraestrutura de armazenamento em cache.- Se o cabeçalho também contiver
hit
oumiss
, o conteúdo solicitado foi considerado não armazenável em cache por alguns componentes de armazenamento em cache e armazenável em cache por outros. - Se o cabeçalho também não contiver
hit
oumiss
, o conteúdo solicitado foi considerado não armazenável em cache por todos os componentes de armazenamento em cache, e todas as solicitações desse conteúdo serão buscadas na origem. Para garantir que seu conteúdo seja armazenado em cache corretamente, revise os requisitos de origem do Media CDN.
- Se o cabeçalho também contiver
Cabeçalhos padrão
O Media CDN adiciona os cabeçalhos de solicitação e resposta a seguir às solicitações de origem e respostas do cliente, respectivamente.
Cabeçalho | Descrição | Request | Resposta |
---|---|---|---|
x-request-id |
Identificador exclusivo da solicitação em questão. Esse valor também é adicionado ao registro de solicitação como jsonPayload.requestId , o que permite correlacionar uma solicitação/resposta do cliente a uma entrada de registro. |
✔ | |
age |
Retorna a idade do objeto armazenado em cache (número de segundos em que ele está no cache). A idade normalmente é calculada com base em quando o objeto foi inicialmente armazenado em cache em um local de cache de cauda longa (escudo). Respostas sem um cabeçalho |
✔ | |
via |
Identifica o Google como o proxy intermediário. Ele está definido como |
✔ | ✔ |
server |
Está definido como Google-Edge-Cache . |
✔ | |
cdn-loop |
Identifica loops, por exemplo, em que o host de origem é o mesmo que o host voltado para o usuário (de borda). Um token de |
✔ | |
forwarded |
A versão estruturada do cabeçalho Esses cabeçalhos permitem identificar o endereço IP do cliente conectado quando um proxy (ou proxies) estão no caminho. Por exemplo, se um
cliente com endereço IP
No caso de vários proxies do lado do cliente, o cliente que se conectou ao Media CDN é o último endereço anexado no valor do cabeçalho. |
✔ | |
x-forwarded-for |
A versão padrão não estruturada e de fato do cabeçalho Os dois cabeçalhos são enviados em uma solicitação para oferecer suporte a origens legadas que podem
não estar cientes do cabeçalho |
✔ |
As chaves de cabeçalho são escritas em letras minúsculas nos cabeçalhos de solicitação e resposta porque não diferenciam maiúsculas de minúsculas.
Outros cabeçalhos, incluindo o local do ponto de presença (PoP, na sigla em inglês) e o status do cache,
como hit
e miss
, podem ser adicionados usando
variáveis de cabeçalho dinâmicas.