Diese Seite wurde von der Cloud Translation API übersetzt.

Benutzerdefinierte Header definieren

Mit Media CDN können Sie benutzerdefinierte Anfrage- und Antwortheader angeben.

Mit benutzerdefinierten Headern haben Sie folgende Möglichkeiten:

Geografische Daten zum Client zurückgeben, z. B. Land, Region oder Stadt, mit denen Sie lokalisierte Inhalte anzeigen können.
Ermitteln, ob eine Antwort vollständig oder teilweise aus dem Cache bereitgestellt wurde und von welchem Cache-Speicherort sie bereitgestellt wurde.
Sowohl Anfrage- als auch Antwortheader entfernen, ersetzen oder anhängen.

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.

Legen Sie benutzerdefinierte Anfrageheader pro Route früh im CDN-Verarbeitungspfad fest, bevor Entscheidungen zum Caching getroffen werden. Wenn Sie beispielsweise einen cache-control-Header als benutzerdefinierten Header pro Route festlegen, wirkt sich das auf das Caching-Verhalten im CDN aus.

Standardmäßig werden hinzugefügte Headerwerte durch Kommas getrennt und den Antwort- oder Anfrageheadern mit denselben Feldnamen angefügt.

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.

Informationen zum Konfigurieren ursprungsspezifischer benutzerdefinierter Header finden Sie unter Ursprungsspezifische Hostumschreibungen oder Header-Änderungen konfigurieren.

Dynamische Headervariablen

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 enthalten, können nicht Teil des Cache-Schlüssels sein.

Variable	Beschreibung	Unterstützt für Anfrageheader	Unterstützt für Anfrageheader in einem Cache-Schlüssel	Unterstützt für Antwortheader
`cdn_cache_status`	Eine kommagetrennte 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 Namen der Orte können US-ASCII-Buchstaben, Zahlen, Leerzeichen und die folgenden Zeichen enthalten: !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	Der Breiten- und Längengrad des Orts, aus dem die Anfrage stammt, 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 entsprechen diese Codes den 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 Übertragungszeit zwischen dem CDN und dem HTTP(S)-Client in Millisekunden. 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. Gültige Werte sind: `DESKTOP`, `MOBILE`, `TABLET`, `SMART_TV`, `GAME_CONSOLE`, `WEARABLE` und `UNDETERMINED`.	✔	✔
`original_request_id`	Die eindeutige Kennung, die der Anfrage zugewiesen wurde, die ursprünglich diese Antwort erzeugt hat. Wird nur ausgefüllt, wenn sie sich von der `request_id` für im Cache gespeicherte Antworten unterscheidet.			✔
`origin_name`	Die Ressource `EdgeCacheOrigin`, von der die Antwort weitergeleitet wurde.			✔
`origin_request_header`	Enthält den Wert des Ursprungsheaders in der Anfrage für Anwendungsfälle mit CORS (Cross-Origin Resource Sharing).			✔
`proxy_status`	Eine Liste der vermittelnden HTTP-Proxys im Antwortpfad. Der Wert ist in RFC 9209 definiert. Eine `EdgeCacheService`-Ressource wird durch `Google-Edge-Cache` dargestellt. Wenn die Antwort vom Ursprung abgerufen wurde, wird eine `EdgeCacheOrigin`-Ressource durch `Google-Edge-Cache-Origin` dargestellt.			✔
`tls_sni_hostname`	Der Servername (gemäß RFC 6066) für die Bereitstellung vom Client während des TLS- oder QUIC-Handshakes. Der Hostname wird 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`. Bei QUIC und unverschlüsselten Clientverbindungen ist dieser Wert leer.	✔		✔
`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 bleiben erhalten, mit Ausnahme der folgenden, die entfernt werden:
- X-User-IP
- Alle Header mit X-Google oder X-GFE
Headerschlüssel und ‑werte müssen RFC 7230 entsprechen. Ältere Formate 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 wie Set-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 und X-Forwarded-For.
Media CDN erweitert jeden Antwortheader mit einer unterstützten Variablen, auch wenn sie vom Client oder Ursprung festgelegt wurde. So können Sie nicht nur benutzerdefinierte Header, sondern auch von Ihrem Client (z. B. ein Videoplayer) oder Ihrer Ursprungsinfrastruktur festlegen. In Media CDN werden Variablen im Anfragepfad nicht erweitert.
Gemäß den oben beschriebenen Regeln werden beispielsweise die Überschriften X-Goog- und X-Amz- beibehalten und in Kleinbuchstaben umgewandelt.

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, wurden die angeforderten Inhalte vom Ursprung abgerufen.
Wenn der Header uncacheable enthält, wurden die angeforderten Inhalte von einigen oder allen Komponenten der Caching-Infrastruktur als nicht im Cache speicherbar eingestuft.
- Wenn der Header auch hit oder miss 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 oder miss 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. Damit deine Inhalte richtig im Cache gespeichert werden, lies dir die Anforderungen an den Ursprung für Media CDN durch.

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 zurück (Anzahl der Sekunden, die es sich im Cache befindet). Das Alter wird in der Regel basierend darauf berechnet, wann das Objekt zum ersten Mal an einem Long-Tail-Cache-Speicherort (Shield) im Cache gespeichert wurde. Antworten ohne `age`-Header werden nicht aus dem Cache bereitgestellt.		✔
`via`	Google wird als Zwischenproxy angegeben. Dieser Wert ist auf `1.1 google` festgelegt und kann nicht geändert werden.	✔	✔
`server`	ist auf `Google-Edge-Cache` gesetzt.		✔
`cdn-loop`	Gibt Schleifen an, z. B. wenn der Ursprungshost mit dem nutzerseitigen Edge-Host identisch ist. Dem Header wird gemäß RFC 8586 ein Token von `google` angehängt. Das Token kann nicht geändert werden.	✔
`forwarded`	Die strukturierte Version des `x-forwarded-for`-Headers. Der `forwarded`-Header ist in RFC 7239 definiert. Anhand dieser Header können Sie die IP-Adresse des Clients ermitteln, der eine Verbindung herstellt, wenn sich ein oder mehrere Proxys im Pfad befinden. Wenn beispielsweise ein Client mit der IP-Adresse `192.0.2.60` eine Verbindung über HTTPS zu Media CDN herstellt, wird der `forwarded`-Header so ausgefüllt: `forwarded: [for=192.0.2.60;proto=https]` Bei mehreren clientseitigen Proxys ist der Client, der eine Verbindung zum Media CDN herstellt, die letzte Adresse, die im Headerwert angehängt wird.	✔
`x-forwarded-for`	Die unstrukturierte und de-facto-Standardversion des `forwarded`-Headers. Die Werte sind in der Regel durch Kommas getrennt. Beide Header werden in einer Anfrage gesendet, um Legacy-Ursprunge zu unterstützen, die den `forwarded`-Header möglicherweise nicht kennen.	✔

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.