Esta página foi traduzida pela API Cloud Translation.

Defina cabeçalhos personalizados

A RFC de multimédia permite-lhe especificar cabeçalhos de pedidos e respostas personalizados.

Os cabeçalhos personalizados permitem-lhe fazer o seguinte:

Devolver dados geográficos sobre o cliente, como o país, a região ou a cidade, que pode usar para mostrar conteúdo localizado.
Determinar se uma resposta foi publicada a partir da cache (total ou parcialmente) e a partir de que localização da cache foi publicada.
Remover, substituir ou anexar aos cabeçalhos de pedido e resposta.

Defina cabeçalhos personalizados

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

Defina cabeçalhos de pedidos personalizados por rota no início do caminho de processamento da RFC, antes das decisões de colocação em cache. Por exemplo, se definir um cabeçalho cache-control como um cabeçalho personalizado por rota, afeta o comportamento de colocação em cache na RFC.

Por predefinição, os valores de cabeçalho adicionados são separados por vírgulas e anexados aos cabeçalhos de resposta ou de pedido com os mesmos nomes de campos.

Para substituir os valores existentes, defina replace como true.

gcloud e YAML

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

gcloud edge-cache services describe prod-media-service

A secção .routing.pathMatchers[].routeRules[].headerAction mostra os cabeçalhos a adicionar e remover:

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 fragmento do Terraform seguinte mostra uma regra de encaminhamento 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 através da variável {client_region}, que devolve o país (ou a região) associado ao endereço IP do cliente.
Adiciona um cabeçalho x-downstream-cdn personalizado ao pedido através de uma string estática.
Remove dois cabeçalhos internos.

Para configurar cabeçalhos personalizados específicos da origem, consulte o artigo Configure reescritas de anfitriões ou modificações de cabeçalhos específicos 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 dos pedidos que fazem parte da política de chaves da cache (cacheKeyPolicy.includedHeaderNames) podem conter uma ou mais variáveis personalizadas. Os cabeçalhos dos pedidos que contêm outras variáveis dinâmicas não podem fazer parte da chave da cache.

Variável	Descrição	Suportado para cabeçalhos de pedidos	Suportado para cabeçalhos de pedidos numa chave de cache	Suportado para cabeçalhos das respostas
`cdn_cache_status`	Uma lista separada por vírgulas das localizações (código da IATA do aeroporto mais próximo) e dos estados de cada nó da cache no caminho do pedido/resposta, em que o valor mais à direita representa a cache mais próxima do utilizador.			✔
`client_city`	O nome da cidade de origem do pedido, por exemplo, `Mountain View` para Mountain View, Califórnia. Não existe uma 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 carateres: !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	A latitude e a longitude da cidade de origem do pedido, por exemplo, `37.386051,-122.083851` para um pedido de Mountain View.	✔		✔
`client_region`	O país (ou a região) associado ao endereço IP do cliente. Este é um código de região CLDR Unicode, como `US` ou `FR`. Para a maioria dos países, estes códigos correspondem diretamente aos códigos ISO-3166-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. É um ID de subdivisão Unicode CLDR, como `USCA` ou `CAON`. Estes códigos Unicode são derivados das subdivisões definidas pela norma ISO-3166-2.	✔	✔	✔
`client_rtt_msec`	O tempo de transmissão de ida e volta estimado entre a RFC e o cliente HTTP(S), em milissegundos. Este é o parâmetro de tempo de resposta suavizado (SRTT) medido pela pilha TCP da RFC, de acordo com a RFC 2988.	✔		✔
`device_request_type`	O tipo de dispositivo que o cliente está a usar. 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 ao pedido que gerou originalmente esta resposta. Preenchido apenas se for diferente de `request_id` para respostas em cache.			✔
`origin_name`	O recurso `EdgeCacheOrigin` a partir do qual a resposta foi encaminhada através de proxy.			✔
`origin_request_header`	Reflete o valor do cabeçalho Origin no pedido para exemplos de utilização da partilha de recursos de origem cruzada (CORS).			✔
`proxy_status`	Uma lista de proxies HTTP intermediários no caminho de resposta. O valor é definido pelo RFC 9209. Um recurso `EdgeCacheService` é representado por `Google-Edge-Cache`. Se a resposta foi obtida a partir da origem, um recurso `EdgeCacheOrigin` é representado por `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	A indicação do nome do servidor (conforme definido na RFC 6066), se for fornecida pelo cliente durante o handshake do TLS ou QUIC. O nome de anfitrião é convertido em minúsculas e todos os pontos finais são removidos.	✔		✔
`tls_version`	A versão do 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 ligar através do QUIC em vez do TLS, o valor é QUIC.	✔		✔
`tls_cipher_suite`	O conjunto de cifras negociado durante o handshake TLS. O valor é definido pelo IANA TLS Cipher Suite Registry, por exemplo, `TLS_RSA_WITH_AES_128_GCM_SHA256`. Este valor está vazio para ligações de clientes QUIC e não encriptadas.	✔		✔
`user_agent_family`	A família de navegadores que o cliente está a usar. 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 aplicam-se às variáveis personalizadas:

Os cabeçalhos de pedidos e respostas existentes são preservados, exceto os seguintes, que são removidos:
- X-User-IP
- Quaisquer cabeçalhos com X-Google ou X-GFE
As chaves e os valores dos cabeçalhos têm de estar em conformidade com a RFC 7230, sendo as formas obsoletas não permitidas.
Todas as chaves de cabeçalho estão em letras minúsculas (de acordo com o HTTP/2).
Alguns cabeçalhos são unidos. Quando existem várias instâncias da mesma chave de cabeçalho (por exemplo, Via), o balanceador de carga combina os respetivos valores numa única lista separada por vírgulas para uma única chave de cabeçalho. Apenas os cabeçalhos cujos valores podem ser representados como uma lista separada por vírgulas são unidos. Outros cabeçalhos, como Set-Cookie, nunca são unidos.
Alguns cabeçalhos são adicionados ou são anexados valores aos mesmos. A RFC sempre adiciona ou modifica determinados cabeçalhos, como X-Forwarded-For.
A RFC 9110 expande qualquer cabeçalho de resposta com uma variável suportada, mesmo que seja definida pelo cliente ou pela origem. Isto permite-lhe definir cabeçalhos dinâmicos a partir do cliente (como um leitor de vídeo) ou da infraestrutura de origem, além de configurar cabeçalhos personalizados. A RFC de multimédia não expande as variáveis no caminho do pedido.
Por exemplo, de acordo com as regras descritas anteriormente, os cabeçalhos X-Goog- e X-Amz- são preservados e convertidos em minúsculas.

Valores do estado da cache

A variável de cabeçalho {cdn_cache_status} pode devolver vários valores correspondentes ao nível da cache que publicou a resposta. Considere as seguintes diretrizes para interpretar a variável de cabeçalho {cdn_cache_status}:

Se o cabeçalho contiver hit, o conteúdo pedido foi obtido a partir da cache.
Se o cabeçalho contiver miss, significa que não foi possível encontrar o conteúdo pedido num nó de cache e que teve de ser obtido a partir de um nó a montante.
Se o cabeçalho contiver fetch, o conteúdo pedido foi obtido a partir da origem.
Se o cabeçalho contiver uncacheable, o conteúdo pedido 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 pedido 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 pedido foi considerado não armazenável em cache por todos os componentes de armazenamento em cache, e todos os pedidos deste conteúdo são obtidos a partir da origem. Para garantir que o seu conteúdo é colocado em cache corretamente, reveja os requisitos de origem da RFC de multimédia.

Cabeçalhos predefinidos

A RFC de multimédia adiciona os seguintes cabeçalhos de pedidos e respostas, respetivamente, aos pedidos de origem e às respostas dos clientes.

Cabeçalho	Descrição	Pedido	Resposta
`x-request-id`	Um identificador exclusivo do pedido em questão. Este valor também é adicionado ao registo de pedidos como `jsonPayload.requestId`, o que lhe permite correlacionar um pedido/resposta do cliente com uma entrada de registo.		✔
`age`	Devolve a idade do objeto em cache (o número de segundos que está na cache). Normalmente, a idade é calculada com base no momento em que o objeto foi inicialmente colocado em cache numa localização de cache de cauda longa (proteção). As respostas sem um cabeçalho `age` não são publicadas a partir da cache.		✔
`server`	Está definido como `Google-Edge-Cache`.		✔
`cdn-loop`	Identifica ciclos, por exemplo, quando o anfitrião de origem é o mesmo que o anfitrião (de limite) virado para o utilizador. É anexado um token de `google` ao cabeçalho de acordo com a RFC 8586. Não é possível alterar o token.	✔
`forwarded`	A versão estruturada do cabeçalho `x-forwarded-for`. O cabeçalho `forwarded` está definido no RFC 7239. Estes cabeçalhos permitem-lhe identificar o endereço IP do cliente que está a estabelecer ligação quando existem um ou mais proxies no caminho. Por exemplo, se um cliente com o endereço IP `192.0.2.60` se ligar ao Media CDN através de HTTPS, o cabeçalho `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 ligou ao Media CDN é o último endereço anexado no valor do cabeçalho.	✔
`x-forwarded-for`	A versão não estruturada e de facto padrão do cabeçalho `forwarded`. Normalmente, os valores são separados por vírgulas. Ambos os cabeçalhos são enviados num pedido para suportar origens antigas que podem não ter conhecimento do cabeçalho `forwarded`.	✔

As chaves dos cabeçalhos são escritas em letras minúsculas para os cabeçalhos de pedidos e respostas, porque as chaves dos cabeçalhos não são sensíveis a maiúsculas e minúsculas.

Pode adicionar outros cabeçalhos, incluindo a localização do ponto de presença (PoP) na extremidade e o estado da cache (como hit e miss), através de variáveis de cabeçalho dinâmicas.

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

Defina cabeçalhos personalizados

gcloud e YAML

Terraform

Variáveis de cabeçalho dinâmicas

Valores do estado da cache

Cabeçalhos predefinidos

Defina cabeçalhos personalizados