Ursprung konfigurieren

Es gibt viele Möglichkeiten, Ursprünge für Media CDN zu konfigurieren. Auf dieser Seite erfahren Sie, wie Sie Ursprünge konfigurieren.

Cloud Storage-Bucket als Ursprung konfigurieren

Media CDN unterstützt Cloud Storage-Buckets als Back-Ends für Inhalte. Jeder Dienst kann auf mehrere Buckets verweisen, indem er Routen für den Host, Pfade und andere Anfrageattribute konfiguriert.

Cloud Storage-Buckets werden konfiguriert, indem die Bucket-URL, z. B. gs://my-bucket, als Ursprungsadresse beim Erstellen einer Ursprungsressource verwendet wird.

Console

  1. Rufe in der Google Cloud -Konsole die Seite Origins (Herkunft) des Media CDN auf.

    Zu „Herkunft“

  2. Klicken Sie auf Ursprung erstellen.

  3. Geben Sie einen Namen für den Ursprung ein. Beispiel: cloud-storage-origin.

  4. Optional: Geben Sie eine Beschreibung ein.

  5. Wählen Sie für die Ursprungsadresse die Option Google Cloud Storage-Bucket auswählen aus.

  6. Rufen Sie Ihren Cloud Storage-Bucket auf und wählen Sie ihn aus.

  7. Behalten Sie für Cloud Storage die Standardprotokoll- und Porteinstellungen bei.

  8. Optional: Wenn Überschreibungen des ursprünglichen Anfrageheaders Vorrang vor Headern haben sollen, die vom Client gesendet oder durch Headeraktionen auf Routenebene verändert wurden, gehen Sie so vor:

    1. Wählen Sie Quellüberschreibung aktivieren aus.
    2. Geben Sie im Bereich Überschriften Überschriften an, indem Sie ein oder mehrere Name/Wert-Paare hinzufügen.

  9. Optional: Wählen Sie einen Failover-Ursprung aus, der für den Fall versucht wird, dass dieser Ursprung nicht mehr erreichbar ist. Sie können dieses Feld später aktualisieren.

  10. Wählen Sie Weiterleitungsbedingungen aus.

  11. Wählen Sie Wiederholbedingungen aus.

  12. Wählen Sie unter Maximale Anzahl von Versuchen die maximale Anzahl von Versuchen aus, um den Cache aus diesem Ursprung zu füllen.

  13. Optional: Geben Sie die folgenden Werte für die Zeitüberschreitung an:

    1. Wählen Sie für Verbindungs-Zeitlimit die maximale Dauer aus, die gewartet werden soll, bis die Ursprungsverbindung hergestellt ist.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.

  14. Optional: Klicken Sie auf Label hinzufügen und geben Sie ein oder mehrere Schlüssel/Wert-Paare an.

  15. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie folgenden gcloud edge-cache origins create-Befehl aus:

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

Ersetzen Sie Folgendes:

  • ORIGIN: der Name des neuen Ursprungs
  • ADDRESS: der Bucket-Name, z. B. gs://my-bucket

Dies ist unabhängig davon, ob der Bucket multiregional, biregional oder regional ist.

Wenn Sie einen Dienst konfigurieren, können Sie Ihre Video-on-Demand-Inhalte an einen Bucket weiterleiten und Livestreaming-Inhalte an einen zweiten Bucket streamen. Das ist nützlich, wenn verschiedene Teams die einzelnen Workflows verwalten. Um die Latenz für die Cache-Füllung zu reduzieren, können Sie die Region eu-media.example.com ebenfalls an einen multiregionalen Cloud Storage-Bucket in der EU und die Region us-media.example.com (oder eine Übereinstimmung in Pfad, Header oder Abfrageparameter) an einen US-basierten Storage-Bucket weiterleiten.

Media CDN-Buckets
Media CDN-Buckets (zum Vergrößern anklicken)

In Fällen, in denen die Schreiblatenz von kritischer Bedeutung ist, z. B. beim Livestreaming mit niedriger Latenz, können Sie einen regionalen Cloud Storage-Endpunkt so nah wie möglich bei Ihren Nutzern konfigurieren.

Anfragen authentifizieren

Du kannst mit einer der folgenden unterstützten Methoden prüfen, ob eine Anfrage von Media CDN stammt:

  • Prüfe, ob die IP-Adresse der Verbindung zu den Cache-Füllungsbereichen des Media CDN gehört. Diese Bereiche werden für alle Kunden freigegeben, werden aber immer von EdgeCacheService-Ressourcen verwendet, wenn eine Verbindung zu einem Ursprung hergestellt wird.
  • Fügen Sie einen benutzerdefinierten Anfrageheader mit einem Tokenwert hinzu, den Sie am Ursprung validieren (z. B. einen zufälligen 16-Byte-Wert). Anfragen, die diesen Wert nicht enthalten, können dann von Ihrem Ursprung abgelehnt werden.

Ursprungsprotokoll konfigurieren

Wenn Ursprünge nur HTTPS (HTTP/1.1 über TLS) oder HTTP/1.1 (ohne TLS) unterstützen, legen Sie das Feld protocol explizit fest. Gehen Sie dazu so vor:

Console

  1. Rufe in der Google Cloud -Konsole die Seite Origins (Herkunft) des Media CDN auf.

    Zu „Herkunft“

  2. Wählen Sie den Ursprung aus und klicken Sie auf Bearbeiten.

  3. Wählen Sie als Protokoll HTTPS oder HTTP aus. Geben Sie für HTTP auch den Port als 80 an.

  4. Klicken Sie auf Ursprung aktualisieren.

gcloud

Führen Sie folgenden gcloud edge-cache origins update-Befehl aus:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Wenn Ihr Ursprung HTTP/2 unterstützt, müssen Sie das Protokoll nicht explizit festlegen.

Private Cloud Storage-Buckets konfigurieren

Media CDN kann Inhalte von jedem über das Internet erreichbaren HTTP- oder HTTPS-Endpunkt abrufen. In einigen Fällen kann es sein, dass Sie eine Authentifizierung erforderlich machen möchten, damit nur Media CDN Inhalte abrufen kann und nicht autorisierter Zugriff verhindert wird. Cloud Storage unterstützt dies über IAM-Berechtigungen.

So gehen Sie bei Cloud Storage-Quellen vor:

  • Dem Media CDN-Dienstkonto die IAM-Berechtigung objectViewer für die Cloud Storage-Buckets gewähren, die du als Ursprung verwendest.
  • Die Berechtigung allUsers entfernen.
  • Optional: Die Berechtigung allAuthenticatedUsers entfernen.

Wenn Sie die Berechtigungen eines Cloud Storage-Bucket ändern möchten, benötigen Sie die IAM-Rolle „Storage Admin“.

Das Media CDN-Dienstkonto gehört zum Media CDN-Projekt und wird nicht in der Liste der Dienstkonten Ihres Projekts angezeigt.

Das Dienstkonto hat das folgende Format und gewährt nur Zugriff auf Media CDN-Ressourcen in den Projekten, die Sie explizit zulassen.

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Um Media CDN Zugriff auf einen Bucket zu gewähren, weisen Sie dem Dienstkonto die Rolle objectViewer zu:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
--role=roles/storage.objectViewer

Verwenden Sie den Befehl gcloud storage buckets remove-iam-policy-binding, um Berechtigungen zu entfernen, die der Rolle allUsers für den angegebenen Bucket gewährt wurden. Wenn der Bucket beispielsweise allUsers die Rolle objectViewer gewährt, entfernen Sie die Berechtigung mit dem folgenden Befehl:

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
--member=allUsers --role=roles/storage.objectViewer

Um zu prüfen, ob der öffentliche Zugriff entfernt wurde, öffnen Sie ein Inkognitofenster und versuchen Sie, mit https://storage.googleapis.com/BUCKET/object.ext auf ein Bucket-Objekt zuzugreifen.

Wenn du EdgeCacheService-Ressourcen in einem Projekt Zugriff auf einen Cloud Storage-Bucket in einem anderen Projekt gewähren möchtest, kannst du dem Media CDN-Dienstkonto in diesem Projekt Zugriff auf den Speicher-Bucket gewähren.

Achten Sie dabei darauf, dass die PROJECT_NUM in service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com die Projektnummer des Projekts mit den EdgeCacheService-Ressourcen ist, die Zugriff benötigen. Sie können dies für mehrere Projekte wiederholen, insbesondere wenn einige davon unterschiedliche Media CDN-Umgebungen (z. B. Entwicklung, Staging oder Produktion) und ein separates Projekt mit Ihren Video- oder Medien-Assets haben.

Sie können den Zugriff auf Ihren Cloud Storage-Ursprung schützen, ohne für diese Route signierte Anfragen zu aktivieren.

Die Konfiguration von privatem Cloud Storage verhindert nicht, dass von Media CDN direkt auf Ihre im Cache gespeicherten Inhalte zugegriffen wird. Informationen darüber, wie Sie signierte Anfragen an einzelne Nutzer senden können, finden Sie unter signierte Anfragen.

Externen Application Load Balancer als Ursprung konfigurieren

Wenn Sie eine aktive Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Compute Engine-, GKE- oder lokale Ursprünge hinweg benötigen, können Sie einen externen Application Load Balancer als Ursprung konfigurieren.

So können Sie beispielsweise Ihre Livestreaming-Verpacker hinter Media CDN oder eine Gruppe von Envoy-Proxys konfigurieren, die von Cloud Service Mesh verwaltet werden, um eine Verbindung zurück zur lokalen Infrastruktur herzustellen.

Mit Load Balancern können Sie Back-Ends für folgende Komponenten konfigurieren:

Eine Architektur, die einen externen Application Load Balancer-Ursprung für die Bereitstellung von Videomanifesten und einen Cloud Storage-Ursprung für die Segmentspeicherung kombiniert, würde folgendermaßen aussehen, wobei zwei Ursprünge verschiedenen Routen zugeordnet werden.

Edge-Cache-Bereitstellung
Edge-Cache-Bereitstellung (zum Vergrößern anklicken)

Wenn Sie einen externen Application Load Balancer als Ursprung konfigurieren möchten, müssen Sie eine Ursprungsressource mit der IP-Adresse oder dem öffentlichen Hostnamen erstellen, die auf die Weiterleitungsregeln Ihres Load Balancers verweist. Ein öffentlicher Hostname (Domainname) wird bevorzugt, da er für ein SSL-(TLS-)Zertifikat und für moderne HTTP-Versionen (HTTP/2 und HTTP/3) erforderlich ist.

Außerdem müssen Sie Folgendes beachten:

  • Ihr Load Balancer hat eine Route, die mit dem Hostnamen übereinstimmt, der für Ihre EdgeCacheService-Ressource verwendet wird, oder Sie haben eine urlRewrite.hostRewrite für Routen konfiguriert, bei denen Ihr Load Balancer als Ursprung konfiguriert ist.
  • Ihr Load Balancer verfügt über ein öffentlich vertrauenswürdiges SSL-(TLS-)Zertifikat, das für diese Hostnamen konfiguriert ist.

Wenn beispielsweise der Name der öffentlichen Domain, der auf die Weiterleitungsregel Ihres Load Balancers verweist, origin-packager.example.com lautet, müssen Sie einen Ursprung erstellen, bei dem die originAddress auf diesen Namen festgelegt ist.

Console

  1. Rufe in der Google Cloud -Konsole die Seite Origins (Herkunft) des Media CDN auf.

    Zu „Herkunft“

  2. Klicken Sie auf Ursprung erstellen.

  3. Geben Sie einen Namen für den Ursprung ein. Beispiel: load-balancer-origin.

  4. Optional: Geben Sie eine Beschreibung ein.

  5. Wählen Sie für die Quelladresse die Option FQDN oder IP-Adresse angeben aus.

  6. Geben Sie den FQDN oder die IP-Adresse für Ihren Google Cloud -Load Balancer ein.

  7. Optional: Wählen Sie einen Failover-Ursprung aus, der für den Fall versucht wird, dass dieser Ursprung nicht mehr erreichbar ist. Sie können dieses Feld später aktualisieren.

  8. Wählen Sie Wiederholbedingungen aus.

  9. Wählen Sie unter Maximale Anzahl von Versuchen die maximale Anzahl von Versuchen aus, um den Cache aus diesem Ursprung zu füllen.

  10. Optional: Geben Sie die folgenden Werte für die Zeitüberschreitung an:

    1. Wählen Sie für Verbindungs-Zeitlimit die maximale Dauer aus, die gewartet werden soll, bis die Ursprungsverbindung hergestellt ist.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.

  11. Optional: Klicken Sie auf Label hinzufügen und geben Sie ein oder mehrere Schlüssel/Wert-Paare an.

  12. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie folgenden gcloud edge-cache origins create-Befehl aus:

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

Ersetzen Sie Folgendes:

  • LB_ORIGIN: der Name der Quelle
  • LB_ADDRESS: der FQDN oder die IP-Adresse, z. B. origin-packager.example.com

Wenn Sie die IP-Adresse Ihrer Weiterleitungsregel als Ursprungsadresse verwenden oder an Ihren Load Balancer kein SSL-Zertifikat angehängt ist, können Sie das Protokoll auf HTTP setzen, um ein Fallback auf unverschlüsselte Verbindungen auszuführen. Wir empfehlen, dies nur für Entwicklungs- oder Testzwecke zu tun.

Ursprungs-Failover konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie das Verhalten beim Failover des Ursprungs konfigurieren.

Ursprungs-Failover ohne Folgen der Weiterleitung

Im Folgenden ist eine grundlegende Failover-EdgeCacheOrigin-Konfiguration aufgeführt:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN versucht, den primären Ursprung der Route maximal dreimal zu erreichen, bevor ein Failover-Ursprung verwendet wird. In dieser Konfiguration versucht Media CDN, nachdem der primäre Ursprung dreimal versucht wurde zu erreichen, eine einzelne Anfrage mit FAILOVER_ORIGIN. Wenn auch der Failover-Ursprung nicht antwortet, gibt Media CDN entweder die vollständige Ursprungsantwort oder, wenn kein Statuscode empfangen wird, eine HTTP-502 Bad Gateway-Antwort zurück.

Die Cache-Auslieferungslatenz steigt mit der Anzahl der Wiederholungen und Failover-Ereignisse. Das Erhöhen der Ursprungs-Zeitlimitwerte (z. B. connectTimeout) wirkt sich weiter auf die Cache-Füllungslatenz aus, weil dadurch die Zeit erhöht wird, die mit dem Warten auf die Antwort eines überlasteten oder ausgelasteten Ursprungsservers verbracht wird.

Das folgende Beispiel zeigt eine Konfiguration, die Füllungsanfragen an MY_ORIGIN sendet. Die Konfiguration bewirkt, dass Media CDN bei Verbindungsfehlern (wie DNS-, TCP- oder TLS-Fehlern), HTTP 5xx-Antworten vom Ursprung oder HTTP 404 Not Found Wiederholungsversuche unternimmt. Nach zwei Versuchen wird auf FAILOVER_ORIGIN umgestellt.

Es werden insgesamt maximal vier Versuche über alle konfigurierten Ursprünge hinweg unternommen: der ursprüngliche Versuch und bis zu drei Wiederholungsversuche. Sie können einen maxAttempts-Wert pro Ursprung konfigurieren, um zu bestimmen, wie viele Wiederholungsversuche ausgeführt werden, bevor ein Failover durchgeführt wird.

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

Ursprungs-Failover mit Folgen von Weiterleitungen

Angenommen, Sie haben die folgenden EdgeCacheOrigin-Ressourcen konfiguriert und die Routen Ihrer EdgeCacheService-Ressource sind so konfiguriert, dass PrimaryOrigin für die Cache-Auslieferung verwendet wird:

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

In diesem Beispiel liest Media CDN, wenn es eine Cache-Füllung durchführt, die Konfiguration der PrimaryOrigin und reagiert entsprechend.

Angenommen, Media CDN stellt als Versuch Nr. 1, den Ursprung zu kontaktieren, eine Verbindung zu primary.example.com her. Wenn primary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.

Angenommen weiter, primary.example.com gibt einen HTTP-302 Found Redirect an Location: b.example.com zurück. Als Versuch Nr. 2, den Ursprung zu kontaktieren, folgt Media CDN der Weiterleitung zu b.example.com. In diesem Fall geschieht Folgendes:

  • Wenn b.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.
  • Wenn b.example.com eine Weiterleitung oder eine Fehlerantwort zurückgibt, erfolgt ein Failover von Media CDN auf den konfigurierten SecondaryOrigin. Das liegt daran, dass PrimaryOrigin in diesem Beispiel für zwei maxAttempts konfiguriert ist.

Wenn Media CDN auf SecondaryOrigin umstellt, verwendet Media CDN die SecondaryOrigin-Konfiguration und versucht, eine Verbindung zu secondary.example.com herzustellen. Dies ist Versuch Nr. 1, den Ursprung zu kontaktieren, und Versuch Nr. 3 insgesamt.

In diesem Fall geschieht Folgendes:

  • Wenn secondary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Auslieferung.
  • Wenn secondary.example.com einen HTTP-302 Found Redirect an Location: c.example.com zurückgibt, versucht Media CDN, c.example.com zu kontaktieren. In diesem Beispiel ist dies Versuch Nr. 2 für SecondaryOrigin und Versuch Nr. 4 insgesamt.

Wenn der Versuch, c.example.com zu kontaktieren, eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung. Wenn der Versuch eine Weiterleitung zurückgibt, für dessen Folgen Media CDN konfiguriert ist, gibt Media CDN den Fehler HTTP 502 Bad Gateway zurück, da die maximale Anzahl von Versuchen zur Kontaktaufnahme mit einem Ursprung erschöpft ist. Media CDN führt unabhängig von EdgeCacheOrigin-Konfigurationen höchstens vier Versuche über alle Ursprünge hinweg durch. Wenn Media CDN schließlich bei der Kontaktaufnahme mit c.example.com fehlschlägt, gibt Media CDN entweder eine 504 Gateway Timeout-Antwort oder eine 502 Bad Gateway-Antwort zurück.

Wenn Sie eine Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg benötigen, können Sie einen externen Application Load Balancer als primären Ursprung konfigurieren.

Folgen von Ursprungsweiterleitungen konfigurieren

Media CDN unterstützt das Folgen von Weiterleitungen, die von Ihrem Ursprung intern während der Cache-Füllung zurückgegeben werden, anstatt Weiterleitungsantworten direkt an den Client zurückzugeben. Wenn Media CDN so konfiguriert ist, dass es Ursprungsweiterleitungen folgt, ruft Media CDN Inhalte vom Weiterleitungsstandort ab, bevor die weitergeleitete Antwort an den Client im Cache gespeichert und zurückgegeben wird. Media CDN folgt domainübergreifenden Weiterleitungen.

Es empfiehlt sich, die Weiterleitung von Ursprüngen nur für vertrauenswürdige und von Ihnen kontrollierte Ursprünge zu konfigurieren. Sie müssen allen Ursprüngen in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte generiert, die von Ihrem EdgeCacheService ausgeliefert werden.

Fügen Sie die folgende Konfiguration zu Ihrer EdgeCacheOrigin-Ressource hinzu, um das Folgen von Ursprungsweiterleitungen zu aktivieren:

name: MY_ORIGIN
originAddress: "DOMAIN_NAME"
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN verwendet das in den Weiterleitungen angegebene Protokoll, um alle Server zu erreichen. Achten Sie darauf, dass alle Server, an die Media CDN weitergeleitet werden könnte, Ihre erforderlichen Protokolle unterstützen. Speziell wenn das Protokoll auf HTTPS, HTTP/2 oder HTTP/3 gesetzt ist, führt Media CDN kein Fallback auf HTTP/1.1-Verbindungen aus, um unsicheren Weiterleitungen zu folgen. Der Host-Header, der an den weitergeleiteten Ursprung gesendet wird, stimmt mit der weitergeleiteten URL überein. Media CDN folgt einer einzelnen Weiterleitung pro EdgeCacheOrigin-Versuch, bevor die endgültige Antwort zurückgegeben oder die Bedingungen für einen erneuten Versuch oder einen Failover ausgewertet werden.

Mit der Einstellung redirectConditions wird festgelegt, bei welchen HTTP-Antwortcodes Media CDN für jeden Ursprung einer Weiterleitung folgt.

Bedingung Beschreibung
MOVED_PERMANENTLY Weiterleitung für Antwortcode HTTP 301 folgen
FOUND Weiterleitung für Antwortcode HTTP 302 folgen
SEE_OTHER Weiterleitung für Antwortcode HTTP 303 folgen
TEMPORARY_REDIRECT Weiterleitung für Antwortcode HTTP 307 folgen
PERMANENT_REDIRECT Weiterleitung für Antwortcode HTTP 308 folgen

Ursprungsspezifische Hostumschreibungen oder Header-Änderungen konfigurieren

Wenn Ihr Ursprung eine ursprungsspezifische Hostumschreibung oder Header-Änderung erfordert, verwenden Sie das folgende originOverrideAction-Konfigurationsbeispiel, um sie festzulegen:

name: FAILOVER_ORIGIN
originAddress: "FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: "FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

Die Einstellung originOverrideAction.hostRewrite hat Vorrang vor allen vorhandenen Headerüberschreibungen, die für Routen konfiguriert sind, die auf diesen Ursprung verweisen.

Sie können mit requestHeadersToAdd eindeutige Header pro Ursprung verwenden, die von diesem bestimmten Ursprung angefordert werden. Ein häufiger Anwendungsfall ist das Hinzufügen statischer Authorization-Header. Da die Header-Manipulationen während der Ursprungsanfrage ausgeführt werden, ersetzen Header, die pro Ursprung hinzugefügt werden, entweder vorhandene Header desselben Feldnamens oder sie werden diesen angefügt. Standardmäßig fügt Media CDN an vorhandene Header an. Wenn Sie vorhandene Header ersetzen möchten, setzen Sie headerAction.replace auf true.

Informationen zum Festlegen von Anfrageheadern pro Route finden Sie unter Benutzerdefinierte Header festlegen.

Fehlerbehebung

Wenn ein Ursprung nicht wie erwartet funktioniert, finden Sie hier Informationen zur Fehlerbehebung.

Nächste Schritte