Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Définir des en-têtes personnalisés

Media CDN vous permet de spécifier des en-têtes de requête et de réponse personnalisés.

Les en-têtes personnalisés vous permettent d'effectuer les opérations suivantes :

Renvoyer les données géographiques du client, telles que le pays, la région ou la ville, que vous pouvez utiliser pour afficher du contenu localisé.
Déterminer si une réponse a été diffusée à partir du cache (en partie ou complètement) et à partir de quel emplacement elle a été diffusée.
Supprimer, remplacer ou ajouter des en-têtes de requête et de réponse.

Appliquer des en-têtes personnalisés

Les en-têtes sont définis sur chaque route, ce qui vous permet d'ajouter et de supprimer des en-têtes pour différents contenus, tels que des fichiers manifestes ou des séquences vidéo.

Définissez des en-têtes de requête personnalisés par route au début du chemin de traitement du CDN, avant les décisions de mise en cache. Par exemple, si vous définissez un en-tête cache-control en tant qu'en-tête personnalisé par route, cela affecte le comportement de mise en cache dans le CDN.

Par défaut, les valeurs d'en-tête ajoutées sont séparées par une virgule et ajoutées aux en-têtes de réponse ou de requête avec les mêmes noms de champs.

Pour écraser les valeurs existantes, définissez replace sur true.

gcloud et YAML

Pour afficher la configuration YAML de la ressource EdgeCacheService, utilisez la commande suivante :

gcloud edge-cache services describe prod-media-service

La section .routing.pathMatchers[].routeRules[].headerAction affiche les en-têtes à ajouter et à supprimer :

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

L'extrait Terraform suivant montre une règle de route avec des en-têtes personnalisés.

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"
    }
  }
}

Cet exemple effectue les opérations suivantes :

Ajoute un en-tête client-geo personnalisé à la réponse (en utilisant la variable {client_region}) pour afficher le pays (ou la région) associé à l'adresse IP du client.
Ajoute un en-tête x-downstream-cdn personnalisé à la requête à l'aide d'une chaîne statique.
Supprime deux en-têtes internes.

Pour configurer des en-têtes personnalisés spécifiques à l'origine, consultez Configurer des réécritures d'hôte ou des modifications d'en-tête spécifiques à l'origine.

Variables d'en-tête dynamiques

Les en-têtes personnalisés peuvent contenir une ou plusieurs variables dynamiques.

Les en-têtes de requête qui font partie d'une règle de clé de cache (cacheKeyPolicy.includedHeaderNames) peuvent contenir une ou plusieurs variables personnalisées. Les en-têtes de requête qui contiennent d'autres variables dynamiques ne peuvent pas faire partie de la clé de cache.

Variable	Description	Compatible avec les en-têtes de requête	Compatible avec les en-têtes de requête dans une clé de cache	Compatible avec les en-têtes de réponse
`cdn_cache_status`	Liste d'emplacements (code IATA de l'aéroport le plus proche) et d'états de chaque nœud de cache dans le chemin de requête/réponse, séparés par des virgules. La valeur la plus à droite représente le cache le plus proche de l'utilisateur.			✔
`client_city`	Nom de la ville d'origine de la requête, par exemple, `Mountain View` pour Mountain View en Californie. Il n'existe pas de liste canonique de valeurs valides pour cette variable. Les noms de villes peuvent contenir des lettres, des chiffres et des espaces au format US-ASCII, ainsi que les caractères suivants : !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	Latitude et longitude de la ville d'origine de la requête, par exemple `37.386051,-122.083851` pour une requête provenant de Mountain View.	✔		✔
`client_region`	Pays (ou région) associé à l'adresse IP du client. Il s'agit d'un code de région CLDR au format Unicode, tel que `US` ou `FR`. Pour la plupart des pays, ces codes correspondent directement aux codes ISO-3166-1 alpha-2.	✔	✔	✔
`client_region_subdivision`	Subdivision (une province ou un État, par exemple) du pays associée à l'adresse IP du client. Il s'agit d'un ID de subdivision CLDR au format Unicode, tel que `USCA` ou `CAON`. Ces codes Unicode sont dérivés des subdivisions définies par la norme ISO-3166-2.	✔	✔	✔
`client_rtt_msec`	Temps de transmission aller-retour estimé entre le CDN et le client HTTP(S), en millisecondes. Il s'agit du paramètre de délai aller-retour lissé (SRTT, Smoothed Round-Trip Time) mesuré par la pile TCP du CDN, conformément à la RFC 2988.	✔		✔
`device_request_type`	Type d'appareil utilisé par le client. Voici les valeurs valides : `DESKTOP`, `MOBILE`, `TABLET`, `SMART_TV`, `GAME_CONSOLE`, `WEARABLE`, et `UNDETERMINED`.	✔	✔
`edge_location_country_code`	Identifie le pays/la région géographique du serveur de cache périphérique Media CDN spécifique qui traite la requête du client. Il s'agit d'un code pays ISO 3166-1 alpha-2, tel que `US` ou `JP`. Ces codes à deux lettres sont dérivés des codes pays officiels définis par la norme ISO 3166-1.	✔		✔
`host`	Nom d'hôte et numéro de port du serveur auquel la requête du client a été initialement envoyée, correspondant à la valeur de l'`Host` en-tête de requête pour HTTP/1.1 ou du `:authority` pseudo-en-tête pour HTTP/2.	✔		✔
`original_request_id`	Identifiant unique attribué à la requête qui a initialement généré cette réponse. Cet élément est renseigné uniquement si ce paramètre est différent de `request_id` pour les réponses mises en cache.			✔
`origin_name`	Ressource `EdgeCacheOrigin` à partir de laquelle la réponse a été envoyée par proxy.			✔
`origin_request_header`	Correspond à la valeur de l'en-tête d'origine dans la requête pour les cas d'utilisation CORS (Cross-Origin Resource Sharing).			✔
`proxy_status`	Liste des proxys HTTP intermédiaires dans le chemin de réponse. La valeur est définie par la RFC 9209. Une ressource `EdgeCacheService` est représentée par `Google-Edge-Cache`. Si la réponse a été récupérée à partir de l'origine, une `EdgeCacheOrigin` ressource est représentée par `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	Indication du nom du serveur (telle que définie dans RFC 6066), si ce nom est fourni par le client lors du handshake TLS ou QUIC. Le nom d'hôte est converti en minuscules et tous les points se trouvant à la fin du nom sont supprimés.	✔		✔
`tls_version`	Version de TLS négociée entre le client et l'équilibreur de charge lors du handshake SSL. Les valeurs possibles incluent `TLSv1`, `TLSv1.1`, `TLSv1.2`, et `TLSv1.3`. Si le client se connecte à l'aide de QUIC au lieu de TLS, la valeur est QUIC.	✔		✔
`tls_cipher_suite`	Suite de chiffrement négociée lors du handshake TLS. La valeur est définie par le Registre des suites de chiffrement TLS de l'IANA. Par exemple, `TLS_RSA_WITH_AES_128_GCM_SHA256`. Cette valeur est vide pour QUIC et pour les connexions clientes non chiffrées.	✔		✔
`user_agent_family`	Famille de navigateurs utilisée par le client. Voici les valeurs valides : `APPLE`, `APPLEWEBKIT`, `BLACKBERRY`, `DOCOMO`, `GECKO`, `GOOGLE`, `KHTML`, `KOREAN`, `MICROSOFT`, `MSIE`, `NOKIA`, `NETFRONT`, `OBIGO`, `OPENWAVE`, `OPERA`, `OTHER`, `POLARIS`, `TELECA`, `SEMC`, `SMIT` et `USER_DEFINED`.	✔	✔

Les considérations suivantes s'appliquent aux variables personnalisées :

Les en-têtes de requêtes et de réponses existants sont conservés, à l'exception des suivants, qui sont supprimés :
- X-User-IP
- Tous les en-têtes avec X-Google ou X-GFE
Les clés et les valeurs d'en-tête doivent être conformes à RFC 7230, les formats obsolètes n'étant pas acceptés.
Toutes les clés d'en-tête sont en minuscules (conformément à la norme HTTP/2).
Certains en-têtes sont fusionnés. Lorsqu'il existe plusieurs instances de la même clé d'en-tête (par exemple, Via), l'équilibreur de charge combine leurs valeurs dans une même liste d'éléments séparés par des virgules correspondant à une clé d'en-tête unique. Seuls les en-têtes dont les valeurs peuvent être représentées sous la forme d'une liste d'éléments séparés par des virgules sont fusionnés. Les autres en-têtes, tels que Set-Cookie, ne sont jamais fusionnés.
Certains en-têtes sont ajoutés ou des valeurs leur sont ajoutées. Media CDN ajoute ou modifie toujours certains en-têtes, tels que X-Forwarded-For.
Media CDN développe tout en-tête de réponse contenant une variable compatible, même s'il est défini par le client ou l'origine. Cela vous permet de définir des en-têtes dynamiques provenant de votre client (tel qu'un lecteur vidéo) ou de votre infrastructure d'origine, en plus de configurer des en-têtes personnalisés.
Par exemple, conformément aux règles décrites précédemment, les en-têtes X-Goog- et X-Amz- sont conservés et mis en minuscules.

Valeurs d'état de cache

La variable d'en-tête {cdn_cache_status} peut renvoyer plusieurs valeurs correspondant au niveau de cache qui a diffusé la réponse. Tenez compte des consignes suivantes pour interpréter la variable d'en-tête {cdn_cache_status} :

Si l'en-tête contient hit, le contenu demandé a été récupéré à partir du cache.
Si l'en-tête contient miss, le contenu demandé n'a pas été trouvé dans un nœud de cache et a dû être récupéré à partir d'un nœud en amont.
Si l'en-tête contient chunked, le contenu demandé n'a pas été trouvé dans un nœud de cache et a dû être récupéré à partir d'un nœud en amont. La réponse en amont n'incluait pas d'en-tête Content-Length.
Si l'en-tête contient fetch, le contenu demandé a été récupéré à partir de l'origine.
Si l'en-tête contient bypassed, le cache a été contourné par la configuration de la requête.
Si l'en-tête contient uncacheable, le contenu demandé a été considéré comme non cachable par certains ou tous les composants de l'infrastructure de mise en cache.
- Si l'en-tête contient également hit ou miss, le contenu demandé a été considéré comme non cachable par certains composants de mise en cache et comme cachable par d'autres.
- Si l'en-tête ne contient pas également hit ou miss, le contenu demandé a été considéré comme non cachable par tous les composants de mise en cache, et toutes les requêtes concernant ce contenu sont récupérées à partir de l'origine. Pour vous assurer que votre contenu est mis en cache de manière appropriée, consultez les exigences concernant l'origineMedia CDN.

En-têtes par défaut

Media CDN ajoute respectivement les en-têtes de requête et de réponse suivants aux requêtes d'origine et aux réponses du client.

En-tête	Description	Requête	Réponse
`x-request-id`	Identifiant unique de la requête en question. Cette valeur est également ajoutée au journal de requêtes en tant que `jsonPayload.requestId`, ce qui vous permet de mettre en corrélation une requête/réponse client avec une entrée de journal.		✔
`age`	Renvoie l'âge de l'objet mis en cache (nombre de secondes de présence dans le cache). L'âge est généralement calculé en fonction du moment où l' objet a été initialement mis en cache dans un emplacement de cache en longue traîne (protection d'origine). Les réponses sans en-tête `age` ne sont pas diffusées à partir du cache.		✔
`server`	Est défini sur `Google-Edge-Cache`.		✔
`cdn-loop`	Identifie les boucles ou "loops", par exemple lorsque l'hôte d'origine est le même que l'hôte visible par l'utilisateur (périphérie). Un jeton de `google` est ajouté à l'en-tête conformément à la RFC 8586. Le jeton ne peut pas être modifié.	✔
`forwarded`	Version structurée de l'en-tête `x-forwarded-for`. L'en-tête `forwarded` est défini dans la RFC 7239. Ces en-têtes vous permettent d'identifier l'adresse IP du client qui se connecte lorsqu'un ou plusieurs proxys sont présents dans le chemin. Par exemple, si un client avec l'adresse IP `192.0.2.60` se connecte à Media CDN via HTTPS, l'en-tête `forwarded` est renseigné comme suit : `forwarded: [for=192.0.2.60;proto=https]` Dans le cas de proxys multiples côté client, le client qui s'est connecté à Media CDN est la dernière adresse ajoutée dans la valeur d'en-tête	✔
`x-forwarded-for`	Version standard de facto et non structurée de l' `forwarded` en-tête. Les valeurs sont généralement séparées par des virgules. Les deux en-têtes sont envoyés dans une requête pour assurer la compatibilité avec les anciennes origines qui peuvent ne pas reconnaître l'en-tête `forwarded`.	✔

Les clés d'en-tête sont en minuscules pour les en-têtes de requête et de réponse, car elles ne sont pas sensibles à la casse.

D'autres en-têtes, notamment l'emplacement du point de présence (PoP) de périphérie et l'état du cache (tel que hit et miss), peuvent être ajoutés à l'aide de variables d'en-tête dynamiques.

Définir des en-têtes personnalisés Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.