Mit Media CDN können Sie benutzerdefinierte Anfrage- und Antwortheader angeben.
Mit benutzerdefinierten Headern haben Sie folgende Möglichkeiten:
- Geografische Daten zum Kunden zurückgeben, z. B. Land, Region oder Stadt mit der du lokalisierte Inhalte präsentieren kannst.
- Ermitteln, ob eine Antwort vollständig oder teilweise aus dem Cache bereitgestellt wurde und von welchem Cache-Speicherort sie bereitgestellt wurde.
- Entfernen, ersetzen oder anhängen Sie Anfrage- und Antwortheader.
Außerdem kannst du Header verwenden, um Anfragen an verschiedene Ursprünge weiterzuleiten. Wenn Sie CORS-Header (Cross-Origin Resource Sharing) konfigurieren müssen, konfigurieren Sie für jede Route eine CORS-Richtlinie.
Benutzerdefinierte Header festlegen
Header werden für jede Route festgelegt. So kannst du Header für verschiedene Inhalte wie Manifeste oder Videosegmente hinzufügen und entfernen.
Standardmäßig werden hinzugefügte Headerwerte durch Kommas getrennt und an die Antwort angehängt oder Anfrageheader mit denselben Feldnamen.
Wenn Sie vorhandene Werte überschreiben möchten, legen Sie replace
auf true
fest.
Im folgenden .routing.pathMatchers[].routeRules[].headerAction
-Beispiel sind Header zu sehen, die einer EdgeCacheService
-Ressource hinzugefügt und daraus entfernt wurden:
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"
Dieses Beispiel tut Folgendes:
- Fügt der Antwort einen benutzerdefinierten
client-geo
-Header unter Verwendung der{client_region}
-Variablen hinzu, der das Land (oder die Region) zurückgibt, das bzw. die der IP-Adresse des Clients zugeordnet ist. - Fügt der Anfrage mithilfe eines statischen Strings einen benutzerdefinierten
x-downstream-cdn
-Header hinzu. - Entfernt zwei interne Überschriften.
Dynamische Header-Variablen
Benutzerdefinierte Header können eine oder mehrere dynamische Variablen enthalten.
Anforderungsheader, die Teil der Cache-Schlüsselrichtlinie (cacheKeyPolicy.includedHeaderNames
) sind, können eine oder mehrere benutzerdefinierte Variablen enthalten. Anfrageheader, die andere
dynamische Variablen nicht Teil des Cache-Schlüssels sein.
Variable | Beschreibung | Unterstützt für Anfrageheader | Wird für Anfrageheader in einem Cache-Schlüssel unterstützt | Unterstützt für Antwortheader |
---|---|---|---|---|
cdn_cache_status |
Eine durch Kommas getrennte Liste der Standorte (IATA-Code des nächstgelegenen Flughafens) und Status jedes Cache-Knotens im Anfrage-/Antwortpfad, wobei der Wert ganz rechts den Cache darstellt, der dem Nutzer am nächsten ist. | ✔ | ||
client_city |
Der Name der Stadt, aus der die Anfrage stammt, z. B. Mountain View für Mountain View, Kalifornien. Für diese Variable gibt es keine offizielle Liste gültiger Werte. Die Städtenamen können
US-ASCII-Buchstaben, Ziffern, Leerzeichen und die folgenden Zeichen enthalten:
!#$%&'*+-.^_`|~ |
✔ | ✔ | |
client_city_lat_long |
Der Breiten- und Längengrad der Stadt, aus der die Anfrage stammt
stammen, z. B. 37.386051,-122.083851
für eine Anfrage aus Mountain View. |
✔ | ✔ | |
client_region |
Das Land oder die Region, das bzw. die der IP-Adresse des Clients zugeordnet ist. Dies ist ein Unicode-CLDR-Regionscode wie US oder FR .
Für die meisten Länder beziehen sich diese Codes direkt auf
ISO-3166-2
Codes. |
✔ | ✔ | ✔ |
client_region_subdivision |
Die Unterteilung des Landes, z. B. eine Region oder ein Bundesstaat, die bzw. der der IP-Adresse des Clients zugeordnet ist. Dies ist eine Unicode-CLDR-Unterteilungs-ID, z. B. USCA oder CAON . Diese Unicode-Codes werden von den durch den ISO-Standard 3166-2 definierten Unterteilungen abgeleitet. |
✔ | ✔ | ✔ |
client_rtt_msec |
Die geschätzte Umlaufzeit zwischen dem CDN und dem HTTP(S)-Client in Millisekunden angeben. Dies ist der Parameter der ausgeglichenen Umlaufzeit (Smoothed Round-Trip Time, SRTT), der vom TCP-Stack des CDNs gemäß RFC 2988 ermittelt wird. | ✔ | ✔ | |
device_request_type |
Der vom Kunden verwendete Gerätetyp. Dies sind die gültigen
Werte: DESKTOP , MOBILE ,
TABLET , SMART_TV ,
GAME_CONSOLE , WEARABLE
und UNDETERMINED . |
✔ | ✔ | |
original_request_id |
Die eindeutige Kennung der Anfrage, die ursprünglich
hat diese Antwort generiert. Wird nur ausgefüllt, wenn es sich von
request_id für im Cache gespeicherte Antworten. |
✔ | ||
origin_name |
Die Ressource EdgeCacheOrigin , von der die Antwort weitergeleitet wurde. |
✔ | ||
origin_request_header |
Gibt den Wert des Origin-Headers in der Anfrage für Cross-Origin wieder Anwendungsfälle für die Ressourcenfreigabe (CORS) | ✔ | ||
proxy_status |
Eine Liste der vermittelnden HTTP-Proxys im Antwortpfad. Der Wert
ist definiert durch
RFC 9209.
Eine EdgeCacheService -Ressource wird durch
Google-Edge-Cache . Wenn die Antwort vom Ursprung abgerufen wurde, wird eine EdgeCacheOrigin -Ressource durch Google-Edge-Cache-Origin dargestellt. |
✔ | ||
tls_sni_hostname |
Die Angabe des Servernamens (gemäß Definition in RFC 6066), wenn die vom Client während des TLS- oder QUIC-Handshakes bereitgestellt werden. Der Hostname lautet in Kleinbuchstaben konvertiert und alle nachgestellten Punkte werden entfernt. | ✔ | ✔ | |
tls_version |
Die TLS-Version, die während des SSL-Handshakes zwischen Client und Load Balancer ausgehandelt wird. Mögliche Werte sind TLSv1 , TLSv1.1 , TLSv1.2 und TLSv1.3 . Stellt der Client eine Verbindung mit QUIC statt TLS her, so lautet der Wert QUIC. |
✔ | ✔ | |
tls_cipher_suite |
Die Cipher Suite, die während des TLS-Handshakes ausgehandelt wird. Der Wert wird von der IANA TLS Cipher Suite Registry definiert, z. B. TLS_RSA_WITH_AES_128_GCM_SHA256 . Dieser Wert ist leer
für QUIC- und unverschlüsselte Clientverbindungen. |
✔ | ✔ | |
user_agent_family |
Die Browserfamilie, die der Kunde verwendet. Gültige Werte sind: APPLE , APPLEWEBKIT , BLACKBERRY , DOCOMO , GECKO , GOOGLE , KHTML , KOREAN , MICROSOFT , MSIE , NOKIA , NETFRONT , OBIGO , OPENWAVE , OPERA , OTHER , POLARIS , TELECA , SEMC , SMIT und USER_DEFINED . |
✔ | ✔ |
Für benutzerdefinierte Variablen gilt Folgendes:
Vorhandene Anfrage- und Antwortheader werden beibehalten, mit Ausnahme der folgenden, die entfernt werden:
X-User-IP
- Alle Header mit
X-Google
oderX-GFE
Header-Schlüssel und -Werte müssen RFC-konform sein. 7230 mit Veraltete Formulare sind nicht zulässig.
Alle Headerschlüssel werden gemäß HTTP/2 in Kleinbuchstaben geschrieben.
Einige Header werden zusammengeführt. Wenn mehrere Instanzen mit demselben Headerschlüssel vorhanden sind, z. B.
Via
, kombiniert der Load-Balancer deren Werte in einer durch Kommas getrennten Liste zu einem einzelnen Headerschlüssel. Es werden nur Header zusammengeführt, deren Werte als durch Kommas getrennte Liste dargestellt werden können. Andere Header wieSet-Cookie
werden nie zusammengeführt.Einige Header werden hinzugefügt oder Werte werden an sie angehängt. Media CDN fügt bestimmte Header immer hinzu oder ändert sie, z. B.
Via
undX-Forwarded-For
.Media CDN erweitert jeden Antwortheader mit einem unterstützten auch dann, wenn sie vom Client oder Ursprung festgelegt wurde. Dadurch können Sie legen dynamische Header von Ihrem Client (z. B. einem Videoplayer) oder vom Ursprung fest. und Infrastruktur konfigurieren sowie benutzerdefinierte Header konfigurieren. Media CDN erweitert Variablen im Anfragepfad nicht.
Gemäß den zuvor beschriebenen Regeln können beispielsweise
X-Goog-
undX-Amz-
-Header werden beibehalten und kleingeschrieben.
Cache-Statuswerte
Die {cdn_cache_status}
-Headervariable kann mehrere Werte zurückgeben, die der Cacheebene entsprechen, von der die Antwort gesendet wurde. Beachten Sie die folgenden Richtlinien für die Interpretation der Headervariablen {cdn_cache_status}
:
- Wenn der Header
hit
enthält, wurden die angeforderten Inhalte aus dem Cache abgerufen. - Wenn der Header
miss
enthält, wurden die angeforderten Inhalte nicht in einem Cacheknoten gefunden und mussten von einem vorgelagerten Knoten abgerufen werden. - Wenn der Header
fetch
enthält, war der angeforderte Inhalt aus dem Ursprung abgerufen werden. Wenn der Header
uncacheable
enthält, war der angeforderte Inhalt werden von einigen oder allen Caching-Komponenten nicht im Cache gespeichert. und Infrastruktur.- Wenn der Header auch
hit
odermiss
enthält, wurden die angeforderten Inhalte von einigen Caching-Komponenten als nicht im Cache speicherbar und von anderen als im Cache speicherbar eingestuft. - Wenn der Header nicht auch
hit
odermiss
enthält, wurden die angeforderten Inhalte von allen Caching-Komponenten als nicht im Cache speicherbar eingestuft und alle Anfragen für diese Inhalte werden vom Ursprung abgerufen. Um sicherzustellen, dass Ihre Inhalte ordnungsgemäß im Cache gespeichert werden, dem Media CDN-Ursprung Anforderungen.
- Wenn der Header auch
Standard-Header
Media CDN fügt den Ursprungsanfragen bzw. Clientantworten die folgenden Anfrage- und Antwortheader hinzu.
Header | Beschreibung | Anfrage | Antwort |
---|---|---|---|
x-request-id |
Eine eindeutige Kennung für die jeweilige Anfrage. Dieser Wert wird auch dem Anfrageprotokoll als jsonPayload.requestId hinzugefügt, sodass Sie eine Clientanfrage/-antwort mit einem Logeintrag in Beziehung setzen können. |
✔ | |
age |
Gibt das Alter des im Cache gespeicherten Objekts in Sekunden zurück. im Cache). Das Alter wird in der Regel auf Grundlage des Zeitpunkts berechnet, -Objekt wurde ursprünglich an einem Speicherort im Longtail-Cache (Shield) im Cache gespeichert. Antworten ohne |
✔ | |
via |
Google als Zwischenproxy identifiziert. Dies ist auf |
✔ | ✔ |
server |
Ist auf Google-Edge-Cache festgelegt. |
✔ | |
cdn-loop |
Identifiziert Schleifen, z. B., wo der Ursprungshost der wie der für den Nutzer sichtbare Edge-Host. Das Token |
✔ | |
forwarded |
Die strukturierte Version des Headers „ Anhand dieser Header können Sie die IP-Adresse der Verbindung
Client, wenn sich ein oder mehrere Proxys im Pfad befinden. Wenn zum Beispiel ein
Client mit der IP-Adresse „
Bei mehreren clientseitigen Proxys ist der Client, der eine Verbindung „Media CDN“ ist die letzte an den Header angehängte Adresse Wert. |
✔ | |
x-forwarded-for |
Die unstrukturierte und De-facto-Standardversion der
Beide Header werden in einer Anfrage gesendet, um Legacy-Ursprünge zu unterstützen, die möglicherweise
den |
✔ |
Header-Schlüssel werden sowohl für Anfrage- als auch für Antwortheader in Kleinbuchstaben geschrieben, da bei Header-Schlüsseln die Groß- und Kleinschreibung nicht beachtet wird.
Andere Header, einschließlich des Edge-PoP-Standorts (Point of Presence) und des Cache-Status (z. B. hit
und miss
), können mithilfe von dynamischen Headervariablen hinzugefügt werden.