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 Kunden zurückgeben, z. B. Land, Region oder Stadt mit der du lokalisierte Inhalte präsentieren kannst.
Bestimmt, 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.

Sie können Header verwenden, um Anfragen an verschiedene Ursprünge. Wenn Sie Cross-Origin konfigurieren müssen CORS-Header (Ressourcenfreigabe), konfigurieren Sie ein CORS-Element für jede Route.

Benutzerdefinierte Header festlegen

Header werden für jede Route festgelegt, sodass Sie Header für verschiedene Inhalte wie Manifeste oder Videosegmente.

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, setzen Sie replace auf true.

Das folgende .routing.pathMatchers[].routeRules[].headerAction-Beispiel zeigt Header, 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 mithilfe der Methode einen benutzerdefinierten client-geo-Header hinzu {client_region}, die das zugehörige Land (oder die zugehörige Region) zurückgibt durch die IP-Adresse des Clients.
Fügt der Anfrage mithilfe eines statischen Elements einen benutzerdefinierten x-downstream-cdn-Header hinzu .
Entfernt zwei interne Header.

Dynamische Header-Variablen

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 nicht Teil des Cache-Schlüssels sein.

Variable	Beschreibung	Für Anfrageheader unterstützt	Wird 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/Antwort-Pfad, wobei der Der Wert ganz rechts steht für den 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 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. Dieses ist ein Unicode-CLDR-Regionscode, z. B. `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. die Provinz oder das Bundesland die mit der IP-Adresse des Clients verknüpft sind. Dies ist eine Unicode-CLDR-Unterteilung ID, z. B. `USCA` oder `CAON`. Diese Unicode-Codes werden 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 Client 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 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 definiert durch RFC 9209. Eine `EdgeCacheService`-Ressource wird durch `Google-Edge-Cache`. Wenn die Antwort vom Ursprung abgerufen wurde, `EdgeCacheOrigin` Ressource wird 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 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`. Wenn der Client eine Verbindung über QUIC statt über TLS ist der Wert QUIC.	✔		✔
`tls_cipher_suite`	Die Cipher Suite, die während des TLS-Handshakes ausgehandelt wird. Der Wert ist definiert von der IANA TLS Cipher Suite Registry, 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 Client 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 gelten folgende Überlegungen:

Vorhandene Anfrage- und Antwortheader bleiben erhalten, mit Ausnahme der die entfernt wurden:
- 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 niemals 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 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- und X-Amz--Header werden beibehalten und kleingeschrieben.

Cache-Statuswerte

Die Headervariable {cdn_cache_status} kann mehrere Werte zurückgeben der der Ebene des Caches entspricht, 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, war der angeforderte Inhalt nicht in einem Cache-Knoten gefunden und von einem vorgelagerten Knoten abgerufen werden mussten.
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 oder miss enthält, wird der Der angeforderte Inhalt wurde von einigen Caching-Komponenten als nicht im Cache speicherbar eingestuft. und von anderen im Cache speicherbar sind.
- Enthält der Header nicht auch hit oder miss, der angeforderte Inhalt wurde als nicht im Cache speicherbar eingestuft von allen Caching-Komponenten, und alle Anfragen für diese Inhalte werden abgerufen. vom Ursprung entfernt. Um sicherzustellen, dass Ihre Inhalte ordnungsgemäß im Cache gespeichert werden, Media CDN-Ursprung Anforderungen.

Standardheader

Media CDN fügt folgende Anfrage- und Antwortheader Ursprungsanfragen bzw. Clientantworten.

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 gesendet von Cache gespeichert werden.		✔
`via`	Identifiziert Google als Zwischenproxy. Dies ist auf `1.1 google` festgelegt und kann nicht geändert werden.	✔	✔
`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 `google` wird wie folgt an den Header angehängt: RFC 8586. Das Token kann nicht geändert werden.	✔
`forwarded`	Die strukturierte Version des Headers „`x-forwarded-for`“. Der `forwarded`-Header ist definiert in RFC 7239. 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. 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.