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 onde o pedido foi originado, 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, números, espaços e os seguintes carateres US-ASCII: !#$%&'*+-.^_`|~.
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 Unicode CLDR, 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.
host O anfitrião e o número da porta do servidor para o qual o pedido do cliente foi originalmente enviado, correspondente ao valor do cabeçalho do pedido Host para HTTP/1.1 ou o pseudo-cabeçalho :authority para HTTP/2.
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 de 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 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 norma