Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Definir cabeçalhos personalizados

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

Os cabeçalhos personalizados permitem fazer o seguinte:

Retornar dados geográficos sobre o cliente, como país, região ou cidade, que podem ser usados para mostrar conteúdo localizado.
Determinar se uma resposta foi veiculada do cache (total ou parcialmente) e de qual local de cache ela foi veiculada.
Remover, substituir ou anexar cabeçalhos de solicitação e resposta.

Definir cabeçalhos personalizados

Os cabeçalhos são definidos em cada rota, o que permite adicionar e remover cabeçalhos para diferentes conteúdos, como manifestos ou segmentos de vídeo.

Defina cabeçalhos de solicitação personalizados por rota no início do caminho de processamento da CDN, antes das decisões de armazenamento em cache. Por exemplo, se você definir um cabeçalho cache-control como um cabeçalho personalizado por rota, ele afetará o comportamento de armazenamento em cache na CDN.

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 campo.

Para substituir os valores atuais, defina replace como true.

gcloud e YAML

Para listar a configuração do YAML para o recurso EdgeCacheService, use o seguinte comando:

gcloud edge-cache services describe prod-media-service

A seção .routing.pathMatchers[].routeRules[].headerAction mostra os cabeçalhos a serem adicionados e removidos:

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"

Terraform

O snippet do Terraform a seguir mostra uma regra de rota com cabeçalhos personalizados.

route_rule {
  description = "video routes"
  priority    = 1
  match_rule {
    prefix_match = "/video/"
  }
  origin = google_network_services_edge_cache_origin.default.name
  header_action {
    response_header_to_add {
      # Return the country (or region) associated with the client's IP address.
      header_name  = "client-geo"
      header_value = "{client_region}"
      replace      = true
    }
    request_header_to_add {
      # Inform the upstream origin server that the request is from Media CDN.
      header_name  = "x-downstream-cdn"
      header_value = "Media CDN"
    }
    response_header_to_remove {
      header_name = "X-User-ID"
    }
    response_header_to_remove {
      header_name = "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.

Para configurar cabeçalhos personalizados específicos da origem, consulte Configurar reescritas de host ou modificações de cabeçalho específicas da origem.

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 US-ASCII, números, espaços e os seguintes caracteres: !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	A latitude e 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 de região Unicode CLDR, como `US` ou `FR`. Na maioria dos países, esses códigos correspondem diretamente a códigos ISO-3166-1 alfa-2.	✔	✔	✔
`client_region_subdivision`	A subdivisão (por exemplo, a província ou o estado) do país associado 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`	O tempo estimado de retorno para 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.	✔		✔
`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`.	✔	✔
`host`	O host e o número da porta do servidor para o qual a solicitação do cliente foi originalmente enviada, correspondente ao valor do `Host` cabeçalho da solicitação para HTTP/1.1 ou ao `:authority` pseudocabeçalho para HTTP/2.	✔		✔
`original_request_id`	O identificador exclusivo atribuído à solicitação que gerou originalmente essa resposta. Preenchido apenas se for diferente de `request_id` para respostas armazenadas em cache.			✔
`origin_name`	O recurso `EdgeCacheOrigin` do qual a resposta foi encaminhada por proxy.			✔
`origin_request_header`	Reflete o valor do cabeçalho de origem 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 por RFC 9209. Um recurso `EdgeCacheService` é representado por `Google-Edge-Cache`. Se a resposta foi buscada na origem, um `EdgeCacheOrigin` recurso é representado por `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	A indicação do nome do servidor (conforme definido em RFC 6066), caso seja fornecido pelo cliente durante o handshake do TLS ou do QUIC. O nome do host é convertido para 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 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 pelo Registro do pacote de criptografia TLS da IANA. Por exemplo, `TLS_RSA_WITH_AES_128_GCM_SHA256`. Este valor fica em branco para QUIC e conexões do cliente 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 a 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
- Qualquer cabeçalho com X-Google ou X-GFE
As chaves e os valores de cabeçalho precisam estar em conformidade com RFC 7230, com formulários obsoletos não permitidos.
Todas as chaves de cabeçalho são convertidas 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 X-Forwarded-For.
O Media CDN expande qualquer cabeçalho de resposta com uma variável compatível, mesmo que definida pelo cliente ou pela origem. Isso permite definir cabeçalhos dinâmicos do cliente (como um player de vídeo) ou da infraestrutura de origem, além de configurar cabeçalhos personalizados.
Por exemplo, de acordo com as regras descritas anteriormente, os cabeçalhos X-Goog- e X-Amz- são preservados e convertidos em letras minúsculas.

Valores de status do cache

A variável de cabeçalho {cdn_cache_status} pode retornar vários valores correspondentes à camada 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, o conteúdo solicitado não foi encontrado em um nó de cache e precisou ser recuperado de um nó upstream.
Se o cabeçalho contiver fetch, o conteúdo solicitado foi recuperado da origem.
Se o cabeçalho contiver uncacheable, 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 ou miss, 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 ou miss, 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 são buscadas na origem. Para garantir que o conteúdo seja armazenado em cache corretamente, revise os requisitos de origem do Media CDN.

Cabeçalhos padrão

O Media CDN adiciona os seguintes cabeçalhos de solicitação e resposta às solicitações de origem e respostas do cliente, respectivamente.

Cabeçalho	Descrição	Request	Resposta
`x-request-id`	Um identificador exclusivo para a solicitação. Esse valor também é adicionado ao registro de solicitações 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 (o número de segundos que ele está no cache). A idade é normalmente calculada com base em quando o objeto foi armazenado em cache inicialmente em um local de cache de cauda longa (escudo). As respostas sem um cabeçalho `age` não são veiculadas do cache.		✔
`server`	É definido como `Google-Edge-Cache`.		✔
`cdn-loop`	Identifica loops, por exemplo, quando o host de origem é o mesmo que o host voltado para o usuário (de borda). Um token de `google` é anexado ao cabeçalho de acordo com RFC 8586. O token não pode ser alterado.	✔
`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 cliente de conexão quando um ou mais proxies estão no caminho. Por exemplo, se um cliente com endereço IP `192.0.2.60` se conectar ao Media CDN por HTTPS, o `forwarded` cabeçalho será preenchido da seguinte maneira: `forwarded: [for=192.0.2.60;proto=https]` 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 não estruturada e padrão de fato do `forwarded` cabeçalho. Os valores são normalmente separados por vírgulas. Os dois cabeçalhos são enviados em uma solicitação para oferecer suporte a origens legadas que talvez não conheçam o `forwarded` cabeçalho.	✔

As chaves de cabeçalho são convertidas em letras minúsculas para cabeçalhos de solicitação e resposta, porque elas não diferenciam maiúsculas de minúsculas.

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

Definir cabeçalhos personalizados Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Definir cabeçalhos personalizados

gcloud e YAML

Terraform

Variáveis de cabeçalho dinâmicas

Valores de status do cache

Cabeçalhos padrão

Definir cabeçalhos personalizados