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.
  • Bestimmt, 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, sodass Sie Header für verschiedene Inhalte wie Manifeste oder Videosegmente.

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 pro Route, wirkt sich das auf das Caching-Verhalten im CDN aus.

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 in einer EdgeCacheService-Ressource hinzugefügt und 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 Elements einen benutzerdefinierten x-downstream-cdn-Header hinzu .
  • Entfernt zwei interne Überschriften.

Informationen zum Konfigurieren von ursprungsspezifischen benutzerdefinierten Headern finden Sie unter Herkunftsspezifische Hostumschreibungen oder Headeränderungen konfigurieren

Dynamische Headervariablen

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

Anfrageheader, die Teil der Cache-Schlüsselrichtlinie (cacheKeyPolicy.includedHeaderNames) sind kann 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 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. Der Wert ganz rechts entspricht dem Cache, 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. Es gibt keine kanonische Liste gültiger Werte für diese Variable. 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 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-Unterteilung ID, z. B. USCA oder CAON. Diese Unicode-Codes aus den Untergruppen abgeleitet, die durch die ISO-3166-2 Standard.
client_rtt_msec Die geschätzte Umlaufzeit zwischen dem CDN und dem HTTP(S)-Client in Millisekunden angeben. Dies ist die ausgeglichene Umlaufzeit (SRTT), gemessen vom TCP-Stack des CDN, pro RFC 2988.
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 stammt wurde weitergeleitet.
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 HTTP-zwischengeschalteten Proxys im Antwortpfad. Der Wert ist in RFC 9209 definiert. 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 (wie in den RFC 6066), wenn die vom Client während des TLS- oder QUIC-Handshakes bereitgestellt werden. Der Hostname wird in Kleinbuchstaben konvertiert und alle nachgestellten Punkte werden entfernt.
tls_version Die zwischen dem Client und dem Load-Balancer ausgehandelte TLS-Version während des SSL-Handshakes. 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. Dies sind die gültigen Werte: 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
  • 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 wie Set-Cookie werden nie zusammengeführt.

  • Einige Header werden hinzugefügt oder Werte werden an sie angehängt. Bestimmte Header werden von Media CDN immer hinzugefügt oder geändert, z. B. Via und X-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 oben beschriebenen Regeln werden beispielsweise die Header X-Goog- und X-Amz- beibehalten und in Kleinbuchstaben umgewandelt.

Cache-Statuswerte

Die Headervariable {cdn_cache_status} kann mehrere Werte zurückgeben Sie entspricht der Ebene des Cache, die die Antwort bereitgestellt hat. Berücksichtigen Sie die Beachten Sie dabei die folgenden Richtlinien für die Interpretation der Headervariable {cdn_cache_status}:

  • Wenn der Header hit enthält, wurde der angeforderte Inhalt abgerufen aus dem Cache.
  • 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, 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. Um sicherzustellen, dass Ihre Inhalte ordnungsgemäß im Cache gespeichert werden, dem Media CDN-Ursprung 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 jeweilige Anfrage. Dieser Wert wird auch dem Anfragelog als jsonPayload.requestId hinzu, die können Sie eine Clientanfrage/-antwort einem Logeintrag korrelieren.
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 age-Header werden nicht aus dem Cache bereitgestellt.

via

Identifiziert Google als Zwischenproxy.

Dieser Wert ist auf 1.1 google festgelegt und kann nicht geändert werden.

server ist auf Google-Edge-Cache gesetzt.
cdn-loop

Identifiziert Schleifen, z. B., wo der Ursprungshost der wie der für den Nutzer sichtbare Edge-Host.

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 der Verbindung Client, wenn sich ein oder mehrere Proxys im Pfad befinden. Wenn zum Beispiel ein Client mit der IP-Adresse „192.0.2.60“ stellt eine Verbindung her Media CDN über HTTPS, das forwarded wird wie folgt gefüllt:

forwarded: [for=192.0.2.60;proto=https]

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 forwarded-Header. Die Werte sind in der Regel durch Kommas getrennt.

Beide Header werden in einer Anfrage gesendet, um Legacy-Ursprünge zu unterstützen, die möglicherweise den forwarded-Header nicht kennen.

Headerschlüssel werden sowohl für Anfrage- als auch für Antwortheader in Kleinbuchstaben geschrieben, Bei Schlüsseln wird die Groß-/Kleinschreibung nicht berücksichtigt.

Andere Header, einschließlich Edge-Point-of-Presence (PoP) und Cache Status (z. B. hit und miss) können mit dynamische Headervariablen.