Esta página foi traduzida pela API Cloud Translation.

Definir cabeçalhos personalizados

O Media CDN permite especificar cabeçalhos personalizados de solicitação e resposta.

Os cabeçalhos personalizados permitem o seguinte:

Retornar dados geográficos sobre o cliente, como país, região ou cidade, que você pode usar para exibir conteúdo localizado.
determinar se uma resposta foi fornecida pelo cache (total ou parcialmente) e de qual local de cache foi veiculado.
Remova, substitua ou anexe aos cabeçalhos de solicitação e resposta.

Também é possível usar cabeçalhos para encaminhar solicitações para diferentes origens. Se você precisar configurar o Cross-Origin cabeçalhos de compartilhamento de recursos (CORS), configure um CORS política 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údo diferente, como manifestos ou segmentos de vídeo.

Por padrão, os valores de cabeçalho adicionados são separados por vírgula e anexados à resposta. ou cabeçalhos de solicitação com os mesmos nomes de campo.

Para substituir os valores atuais, defina replace como true.

O exemplo de .routing.pathMatchers[].routeRules[].headerAction a seguir mostra 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 o Variável {client_region}, que retorna o país (ou região) associado pelo endereço IP do cliente.
Adiciona um cabeçalho x-downstream-cdn personalizado à solicitação usando um cabeçalho x-downstream-cdn fio.
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.

Cabeçalhos de solicitação que fazem parte da política de chave de cache (cacheKeyPolicy.includedHeaderNames) pode ter uma ou mais variáveis personalizadas. Os cabeçalhos da 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 dos locais separados por vírgulas (código IATA do aeroporto mais próximo) e os status de cada nó de cache no caminho de solicitação/resposta, em que o 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á lista canônica de valores válidos para esta variável. Os nomes das cidades podem conter letras US-ASCII, números, espaços e os seguintes caracteres: !#$%&'*+-.^_`\|~:	✔		✔
`client_city_lat_long`	A latitude e a longitude da cidade de origem da solicitação originou-se, 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. Isso é um código de região Unicode CLDR, como `US` ou `FR`. Na maioria dos países, esses códigos correspondem diretamente ISO-3166-2 de código aberto.	✔	✔	✔
`client_region_subdivision`	A subdivisão (por exemplo, a província ou o estado) do país associada ao endereço IP do cliente. Esta é uma subdivisão Unicode CLDR ID, como `USCA` ou `CAON`. Esses códigos Unicode são derivadas das subdivisões definidas ISO-3166-2 padrão.	✔	✔	✔
`client_rtt_msec`	O tempo estimado de transmissão de ida e volta entre a CDN e o HTTP(S), em milissegundos. Este é o tempo de retorno suavizado (SRTT) medido pela pilha TCP da CDN, RFC 2988 (link em inglês).	✔		✔
`device_request_type`	O tipo de dispositivo que o cliente está usando. Essas são as métricas válidas valores: `DESKTOP`, `MOBILE`, `TABLET`, `SMART_TV`, `GAME_CONSOLE`, `WEARABLE`, e `UNDETERMINED`.	✔	✔
`original_request_id`	O identificador exclusivo atribuído à solicitação que originalmente gerou esta resposta. Preenchido somente se for diferente de `request_id` para respostas armazenadas em cache.			✔
`origin_name`	O recurso `EdgeCacheOrigin` do qual a resposta foi enviado por proxy.			✔
`origin_request_header`	Reflete o valor do cabeçalho Origin na solicitação de Origens cruzadas Casos de uso do compartilhamento de recursos (CORS).			✔
`proxy_status`	Uma lista de proxies HTTP intermediários no caminho de resposta. O valor é definida pela RFC 9209 (link em inglês). Um recurso `EdgeCacheService` é representado `Google-Edge-Cache`. Se a resposta foi buscada na origem, um(a) `EdgeCacheOrigin` recurso é representado por `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	A indicação do nome do servidor (conforme definido em RFC 6066), se fornecidos pelo cliente durante o handshake de TLS ou QUIC. O nome do host é convertido em 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 de 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 pela IANA, Registro do pacote de criptografia TLS, por exemplo, `TLS_RSA_WITH_AES_128_GCM_SHA256` Este valor está vazio para conexões de cliente QUIC e não criptografadas.	✔		✔
`user_agent_family`	A família de navegadores que o cliente está usando. Essas são as métricas válidas valores: `APPLE`, `APPLEWEBKIT`, `BLACKBERRY`, `DOCOMO` e `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 existentes são preservados, exceto o seguintes, que são removidos:
- X-User-IP
- Todos os cabeçalhos com X-Google ou X-GFE
As chaves e os valores de cabeçalho precisam estar em conformidade com a RFC 7230, com formulários obsoletos não permitidos.
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, como Set-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 e X-Forwarded-For.
O Media CDN expande todos os cabeçalhos de resposta com um link variável, mesmo que definida pelo cliente ou pela origem. Isso permite você define cabeçalhos dinâmicos de seu cliente (como um player de vídeo) ou origem infraestrutura, 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, X-Goog- e Os cabeçalhos X-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 correspondente ao nível de cache que veiculou a resposta. Considere o diretrizes para interpretar a variável de cabeçalho {cdn_cache_status}:

Se o cabeçalho tiver hit, o conteúdo solicitado foi recuperado do cache.
Se o cabeçalho tiver miss, 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 tiver fetch, o conteúdo solicitado foi recuperados da origem.
Se o cabeçalho tiver uncacheable, o conteúdo solicitado foi considerados não armazenáveis em cache por alguns ou todos os componentes do armazenamento do Google Cloud.
- Se o cabeçalho também contiver hit ou miss, o conteúdo solicitado foi considerado não armazenável em cache por alguns componentes de armazenamento em cache e pode ser armazenado em cache por outras pessoas.
- Se o cabeçalho não contiver também hit ou miss, o conteúdo solicitado foi considerado que não pode ser armazenado em cache por todos os componentes de armazenamento em cache, e todas as solicitações desse conteúdo serão buscadas da origem. Para garantir que seu conteúdo seja armazenado em cache corretamente, analise a origem do Media CDN .

Cabeçalhos padrão

O Media CDN adiciona os seguintes cabeçalhos de solicitação e resposta ao 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`, 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 foi no cache). A idade normalmente é calculada com base em quando foi inicialmente armazenado em cache em um local de cache de cauda longa (escudo). As respostas sem um cabeçalho `age` não são veiculadas pelo cache.		✔
`via`	Identifica o Google como o proxy intermediário. Ele está definido como `1.1 google` e não pode ser alterado.	✔	✔
`server`	Está definido como `Google-Edge-Cache`.		✔
`cdn-loop`	Identifica loops, por exemplo, onde o host de origem é o igual ao host voltado para o usuário (de borda). Um token de `google` é anexado ao cabeçalho conforme definido RFC 8586. Não é possível alterar o token.	✔
`forwarded`	A versão estruturada do cabeçalho `x-forwarded-for`. O cabeçalho `forwarded` é definido na RFC 7239. Esses cabeçalhos permitem identificar o endereço IP do endereço IP cliente quando um proxy (ou proxies) estiverem no caminho. Por exemplo, se um cliente com endereço IP `192.0.2.60` se conecta CDN de mídia sobre HTTPS, o `forwarded` é preenchido da seguinte forma: `forwarded: [for=192.0.2.60;proto=https]` No caso de vários proxies do lado do cliente, o cliente que se conectou O Media CDN é o último endereço anexado ao cabeçalho .	✔
`x-forwarded-for`	A versão padrão não estruturada e de fato Cabeçalho `forwarded`. Os valores normalmente são separados por vírgulas. Ambos os cabeçalhos são enviados em uma solicitação para dar suporte a origens legadas que podem não conheça o cabeçalho `forwarded`.	✔

As chaves de cabeçalho estão em minúsculas nos cabeçalhos de solicitação e resposta porque o cabeçalho não diferenciam maiúsculas de minúsculas.

Outros cabeçalhos, incluindo o local e o cache do ponto de presença (PoP) da borda (como hit e miss), pode ser adicionado usando variáveis de cabeçalho dinâmicas.