Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Benutzerdefinierte Header definieren

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

Benutzerdefinierte Header ermöglichen Folgendes:

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.
Anfrage- und Antwortheader entfernen, ersetzen oder anhängen.

Benutzerdefinierte Header festlegen

Header werden für jede Route festgelegt. So können Sie 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 dies auf das Caching-Verhalten im CDN aus.

Standardmäßig werden hinzugefügte Headerwerte kommagetrennt und an die Antwort- oder Anfrageheader mit denselben Feldnamen angehängt.

Wenn Sie vorhandene Werte überschreiben möchten, legen Sie replace auf true fest.

gcloud und YAML

Verwenden Sie den folgenden Befehl, um die YAML-Konfiguration für die EdgeCacheService-Ressource aufzulisten:

gcloud edge-cache services describe prod-media-service

Im Abschnitt .routing.pathMatchers[].routeRules[].headerAction werden die Header angezeigt, die hinzugefügt und entfernt werden sollen:

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

Das folgende Terraform-Snippet zeigt eine Routenregel mit benutzerdefinierten Headern:

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

Dieses Beispiel tut Folgendes:

Fügt der Antwort einen benutzerdefinierten client-geo-Header mit der Variablen {client_region} hinzu, die das Land oder die Region zurückgibt, das bzw. die der IP-Adresse des Clients zugeordnet ist.
Fügt der Anfrage mit einem statischen String einen benutzerdefinierten x-downstream-cdn-Header hinzu.
Entfernt zwei interne Header.

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

Dynamische Header-Variablen

Benutzerdefinierte Header können eine oder mehrere dynamische Variablen enthalten.

Anfrageheader, 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	Für Anfrageheader unterstützt	Für Anfrageheader in einem Cache-Schlüssel unterstützt	Für Antwortheader unterstützt
`cdn_cache_status`	Eine durch Kommas getrennte Liste der Standorte (IATA-Code des nächstgelegenen Flughafens) und Status der einzelnen Cache-Knoten 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 der Stadt, aus der 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 direkt den ISO-3166-1 Alpha-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. Dabei kann es sich um eine Unicode-CLDR-Unterteilungs ID wie `USCA` oder `CAON` handeln. 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 CDN gemäß RFC 2988 ermittelt wird.	✔		✔
`device_request_type`	Der Gerätetyp, den der Client verwendet. Gültige Werte sind: `DESKTOP`, `MOBILE`, `TABLET`, `SMART_TV`, `GAME_CONSOLE`, `WEARABLE` und `UNDETERMINED`.	✔	✔
`host`	Der Host und die Portnummer des Servers, an den die Clientanfrage ursprünglich gesendet wurde. Entspricht dem Wert des `Host` Anfrageheaders für HTTP/1.1 oder dem `:authority` Pseudo-Header für HTTP/2.	✔		✔
`original_request_id`	Die eindeutige Kennung, die der Anfrage zugewiesen wurde, mit der diese Antwort ursprünglich generiert wurde. Wird nur ausgefüllt, wenn sie sich von `request_id` für im Cache gespeicherte Antworten unterscheidet.			✔
`origin_name`	Die `EdgeCacheOrigin` Ressource, von der die Antwort weitergeleitet wurde.			✔
`origin_request_header`	Zeigt den Wert des Ursprungsheaders in der Anfrage für Anwendungsfälle mit CORS (Cross-Origin Resource Sharing) an.			✔
`proxy_status`	Eine Liste der 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, 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` und `TLSv1.2`.`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 Client 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 oder X-GFE
Headerschlüssel und -werte müssen RFC 7230 entsprechen. Ältere Formate sind nicht zulässig.
Alle Headerschlüssel werden in Kleinbuchstaben umgewandelt (gemäß HTTP/2).
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 immer bestimmte Header wie X-Forwarded-For hinzu oder ändert sie.
Media CDN erweitert jeden Antwortheader mit einer unterstützten Variablen, auch wenn er vom Client oder Ursprung festgelegt wurde. Sie können nicht nur benutzerdefinierte Header, sondern auch dynamische Header von Ihrem Client (z. B. ein Videoplayer) oder Ihrer Ursprungsinfrastruktur festlegen.
Gemäß den zuvor beschriebenen Regeln werden beispielsweise X-Goog-\- und X-Amz--Header beibehalten und in Kleinbuchstaben umgewandelt.

Cache-Statuswerte

Die Header-Variable {cdn_cache_status} kann mehrere Werte zurückgeben, die der Cache-Ebene entsprechen, von der die Antwort bereitgestellt wurde. Beachten Sie die folgenden Richtlinien zum Interpretieren der Header-Variablen {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 Cache-Knoten gefunden und mussten von einem Upstream-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 cachefähig eingestuft.
- Wenn der Header auch hit oder miss enthält, wurden die angeforderten Inhalte von einigen Caching-Komponenten als nicht cachefähig und von anderen als cachefähig eingestuft.
- Wenn der Header nicht auch hit oder miss enthält, wurden die angeforderten Inhalte von allen Caching-Komponenten als nicht cachefähig eingestuft und alle Anfragen für diese Inhalte werden vom Ursprung abgerufen. Damit Ihre Inhalte ordnungsgemäß im Cache gespeichert werden, lesen Sie die Media CDN Ursprungs anforderungen.

Standardheader

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 angegebene Anfrage. Dieser Wert wird auch dem Anfragelog als `jsonPayload.requestId` hinzugefügt . So können Sie eine Clientanfrage/-antwort mit einem Logeintrag korrelieren .		✔
`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 anhand des Zeitpunkts berechnet, zu dem das Objekt ursprünglich an einem Longtail-Cache-Standort (Shield) im Cache gespeichert wurde. Antworten ohne `age` Header werden nicht aus dem Cache bereitgestellt.		✔
`server`	Ist auf `Google-Edge-Cache` festgelegt.		✔
`cdn-loop`	Gibt Loops an, z. B. wenn der Ursprungshost mit dem nutzerseitigen Edge-Host identisch ist. Gemäß RFC 8586 wird dem Header ein Token `google` angehängt. Das Token kann nicht geändert werden.	✔
`forwarded`	Die strukturierte Version des `x-forwarded-for`-Headers. Der `forwarded` Header ist definiert in RFC 7239. Mit diesen Headern können Sie die IP-Adresse des verbindenden Clients ermitteln, wenn sich ein oder mehrere Proxys im Pfad befinden. Wenn beispielsweise ein Client mit der IP-Adresse `192.0.2.60` über HTTPS eine Verbindung 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 zu Media CDN hergestellt hat, die letzte Adresse, die dem Header Wert angehängt wird.	✔
`x-forwarded-for`	Die unstrukturierte und De-facto-Standardversion des `forwarded` Headers. Werte sind in der Regel kommagetrennt. Beide Header werden in einer Anfrage gesendet, um ältere Ursprünge zu unterstützen, die möglicherweise nicht den `forwarded` Header kennen.	✔

Headerschlüssel werden sowohl für Anfrage- als auch für Antwortheader in Kleinbuchstaben umgewandelt, da bei Headerschlüsseln die Groß-/Kleinschreibung nicht berücksichtigt werden muss.

Andere Header, einschließlich des Edge Point of Presence (PoP)-Standorts und des Cache-Status (z. B. hit und miss), können mit dynamischen Header-Variablen hinzugefügt werden.

Benutzerdefinierte Header definieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.