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 :
- Affichez des données géographiques sur le 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 totalité ou en partie) ; de l'emplacement de cache à partir duquel elle a été diffusée.
- Supprimez, remplacez ou ajoutez à la fois les en-têtes de requête et de réponse.
Vous pouvez également utiliser les en-têtes pour acheminer les requêtes vers différents origines. Si vous devez configurer une origine multi-origine en-têtes CORS, configurez un CORS pour chaque route.
Appliquer des en-têtes personnalisés
Des en-têtes sont définis sur chaque route, ce qui vous permet d'ajouter et de supprimer des en-têtes pour contenus différents, comme des fichiers manifestes ou des séquences vidéo.
Par défaut, les valeurs d'en-tête ajoutées sont séparées par une virgule et ajoutées à la réponse ou des en-têtes de requête avec les mêmes noms de champ.
Pour écraser les valeurs existantes, définissez replace
sur true
.
L'exemple .routing.pathMatchers[].routeRules[].headerAction
suivant montre
en-têtes ajoutés et supprimés dans une ressource 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"
Cet exemple effectue les opérations suivantes :
- Ajoute un en-tête
client-geo
personnalisé à la réponse à l'aide de la méthode La variable{client_region}
, qui renvoie le pays (ou la région) associé avec l'adresse IP du client. - Ajoute un en-tête
x-downstream-cdn
personnalisé à la requête à l'aide d'un en-tête . - Supprime deux en-têtes internes.
Variables d'en-tête dynamiques
Les en-têtes personnalisés peuvent contenir une ou plusieurs variables dynamiques.
En-têtes de requête faisant partie de la stratégie de clé de cache (cacheKeyPolicy.includedHeaderNames
)
peut contenir une ou plusieurs variables personnalisées. Les en-têtes de requête contenant d'autres
et les variables dynamiques ne peuvent pas faire partie de la clé de cache.
Variable | Description | Compatible avec les en-têtes de requêtes | Pris en charge pour les en-têtes de requêtes dans une clé de cache | Compatible avec les en-têtes de réponse |
---|---|---|---|---|
cdn_cache_status |
Liste des lieux séparés par une virgule (code IATA de l'aéroport le plus proche) et les états de chaque nœud de cache dans le chemin de requête/réponse, où le la valeur la plus à droite représente le cache le plus proche de l'utilisateur. | ✔ | ||
client_city |
Nom de la ville d'où provient la requête (par exemple,
Mountain View pour Mountain View, Californie. Il n'y a aucun
liste canonique de valeurs valides pour cette variable. Les noms des 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'où provient 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. Ce
correspond à un code de région CLDR au format Unicode, tel que US ou FR .
Pour la plupart des pays, ces codes correspondent directement
ISO-3166-2
codes. |
✔ | ✔ | ✔ |
client_region_subdivision |
Subdivision du pays (la province ou l'État, par exemple)
associées à l'adresse IP du client. Il s'agit d'une subdivision CLDR au format Unicode
ID, tel que USCA ou CAON . Ces codes Unicode
sont issues des subdivisions définies par le
ISO-3166-2
standard. |
✔ | ✔ | ✔ |
client_rtt_msec |
Le temps de transmission aller-retour estimé entre le CDN et le client HTTP(S), en millisecondes. Il s'agit du temps aller-retour lissé (SRTT) mesuré par la pile TCP du CDN, RFC 2988 | ✔ | ✔ | |
device_request_type |
Type d'appareil utilisé par le client. Il s'agit des valeurs
valeurs: DESKTOP , MOBILE ,
TABLET , SMART_TV
GAME_CONSOLE , WEARABLE
et UNDETERMINED . |
✔ | ✔ | |
original_request_id |
Identifiant unique attribué à la demande qui a été
a généré cette réponse. Renseigné uniquement si la valeur est différente de
request_id pour les réponses mises en cache. |
✔ | ||
origin_name |
La ressource EdgeCacheOrigin à partir de laquelle la réponse
a été envoyé par proxy. |
✔ | ||
origin_request_header |
Reflète la valeur de l'en-tête "Origin" dans la requête de multi-origine Cas d'utilisation du partage de ressources (CORS) | ✔ | ||
proxy_status |
Liste des proxys HTTP intermédiaires dans le chemin de réponse. La valeur
est défini par
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,
un(e) EdgeCacheOrigin
ressource est représentée par Google-Edge-Cache-Origin . |
✔ | ||
tls_sni_hostname |
Indication du nom du serveur (tel que défini dans RFC 6066), si fournies par le client lors du handshake TLS ou QUIC. Le nom d'hôte est converti en minuscules et tout point final est supprimé. | ✔ | ✔ | |
tls_version |
Version TLS négociée entre le client et l'équilibreur de charge
lors du handshake SSL. Les valeurs possibles sont 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 |
La suite de chiffrement négociée lors du handshake TLS. La valeur est définie
par l'IANA
Registre de la suite de chiffrement TLS, par exemple
TLS_RSA_WITH_AES_128_GCM_SHA256 Cette valeur est vide
pour les connexions client QUIC et non chiffrées. |
✔ | ✔ | |
user_agent_family |
La famille de navigateurs utilisée par le client. Il s'agit des valeurs
valeurs: APPLE , APPLEWEBKIT ,
BLACKBERRY , DOCOMO , GECKO
GOOGLE , KHTML , KOREAN
MICROSOFT , MSIE , NOKIA ,
NETFRONT , OBIGO , OPENWAVE .
OPERA , OTHER , POLARIS .
TELECA , SEMC , SMIT et
USER_DEFINED |
✔ | ✔ |
Voici quelques points à prendre en compte concernant les variables personnalisées:
Les en-têtes de requête et de réponse existants sont conservés, à l'exception des suivantes, qui sont supprimées:
X-User-IP
- Tous les en-têtes avec
X-Google
ouX-GFE
Les clés et les valeurs d'en-tête doivent être conformes au document RFC 7230, avec formulaires obsolètes non autorisés.
Toutes les clés d'en-tête sont en minuscules (selon 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 queSet-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 systématiquement certains en-têtes, tels que
Via
etX-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 permet Vous avez défini des en-têtes dynamiques à partir de votre client (un lecteur vidéo, par exemple) ou de l'origine infrastructure, en plus de configurer des en-têtes personnalisés. Media CDN ne développe pas les variables sur le chemin d'accès de la requête.
Par exemple, conformément aux règles décrites précédemment,
X-Goog-
et Les en-têtesX-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 d'interprétation de la variable d'en-tête {cdn_cache_status}
suivantes:
- Si l'en-tête contient
hit
, le contenu demandé a été récupéré du cache. - Si l'en-tête contient
miss
, le contenu demandé n'était pas trouvées dans un nœud de cache et devaient être récupérées à partir d'un nœud en amont. - Si l'en-tête contient
fetch
, le contenu demandé était récupéré à partir de l'origine. Si l'en-tête contient
uncacheable
, le contenu demandé était considérés comme ne pouvant pas être mis en cache par tout ou partie des composants de la mise en cache de l'infrastructure.- Si l'en-tête contient également
hit
oumiss
, le le contenu demandé a été considéré comme ne pouvant pas être mis en cache par certains composants de mise en cache et pouvant être mis en cache par d'autres. - Si l'en-tête ne contient pas également
hit
oumiss
, le contenu demandé a été considéré comme ne pouvant pas être mis en cache par tous les composants de mise en cache, et toutes les requêtes pour ce contenu sont récupérées de l'origine. Pour vous assurer que votre contenu est correctement mis en cache, consultez l'origine Media CDN exigences.
- Si l'en-tête contient également
En-têtes par défaut
Media CDN ajoute les en-têtes de requête et de réponse suivants les requêtes d'origine et les réponses du client, respectivement.
En-tête | Description | Requête | Réponse |
---|---|---|---|
x-request-id |
Un 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 corréler une requête/réponse client à une entrée de journal. |
✔ | |
age |
Renvoie l'âge de l'objet mis en cache (nombre de secondes après dans le cache). L'âge est généralement calculé en fonction de la date à laquelle a été initialement mis en cache dans un emplacement de cache à longue traîne (bouclier). Les réponses sans en-tête |
✔ | |
via |
Identifie Google comme proxy intermédiaire. Il est défini sur |
✔ | ✔ |
server |
est défini sur Google-Edge-Cache . |
✔ | |
cdn-loop |
Identifie les boucles. Par exemple, l'hôte d'origine est le identique à l'hôte visible par l'utilisateur (périphérique). Un jeton |
✔ | |
forwarded |
La version structurée de l'en-tête Ces en-têtes vous permettent d'identifier l'adresse IP du serveur
lorsqu'un ou plusieurs proxys se trouvent dans le chemin. Par exemple, si un
Le client dont l'adresse IP est
Dans le cas de plusieurs proxys côté client, le client qui s'est connecté à Media CDN correspond à la dernière adresse ajoutée dans l'en-tête . |
✔ | |
x-forwarded-for |
La version standard non structurée et de facto du
En-tête Les deux en-têtes sont envoyés dans une requête pour prendre en charge d'anciennes origines susceptibles
sans connaître l'en-tête |
✔ |
Les clés des en-têtes sont mises en minuscules pour les en-têtes de requête et de réponse, car les en-têtes les clés ne sont pas sensibles à la casse.
Autres en-têtes, y compris l'emplacement et le cache du point de présence périphérique (PoP)
(par exemple, hit
et miss
), peuvent être ajoutés en utilisant
variables d'en-tête dynamique.