RequestInit

Das RequestInit-Dictionary der Fetch API repräsentiert die Menge von Optionen, die verwendet werden können, um eine Fetch-Anfrage zu konfigurieren.

Sie können ein RequestInit-Objekt in den Request()-Konstruktor oder direkt in den fetch()-Funktionsaufruf übergeben.

Sie können auch ein Request mit einem RequestInit konstruieren und das Request in einen fetch()-Aufruf zusammen mit einem anderen RequestInit übergeben. Wenn Sie dies tun und die gleiche Option in beiden Stellen gesetzt ist, wird der Wert verwendet, der direkt in fetch() übergeben wird.

Instanz-Eigenschaften

attributionReporting Optional Experimentell

Gibt an, dass Sie möchten, dass die Antwort der Anfrage in der Lage sein soll, eine JavaScript-basierte Attributionsquelle oder einen Attributionstrigger zu registrieren. attributionReporting ist ein Objekt mit den folgenden Eigenschaften:

eventSourceEligible

Ein Boolean. Wenn auf true gesetzt, ist die Antwort der Anfrage berechtigt, eine Attributionsquelle zu registrieren. Wenn auf false gesetzt, ist sie nicht berechtigt.

triggerEligible

Ein Boolean. Wenn auf true gesetzt, ist die Antwort der Anfrage berechtigt, einen Attributionstrigger zu registrieren. Wenn auf false gesetzt, ist sie nicht berechtigt.

Weitere Details finden Sie in der Attribution Reporting API.

body Optional

Der Anfragetext enthält Inhalte, die an den Server gesendet werden, beispielsweise in einer POST- oder PUT-Anfrage. Es wird als Instanz eines der folgenden Typen angegeben:

Siehe Einrichten eines Bodys für weitere Details.

browsingTopics Optional Experimentell

Ein Boolean, der angibt, dass die ausgewählten Themen des aktuellen Benutzers in einem Sec-Browsing-Topics-Header mit der zugehörigen Anfrage gesendet werden sollen.

Siehe Verwenden der Topics API für weitere Details.

cache Optional

Der Cache-Modus, den Sie für die Anfrage verwenden möchten. Dies kann einer der folgenden Werte sein:

default

Der Browser sucht in seinem HTTP-Cache nach einer Antwort, die der Anfrage entspricht.

  • Wenn es eine Übereinstimmung gibt und sie frisch ist, wird sie aus dem Cache zurückgegeben.
  • Wenn es eine Übereinstimmung gibt, die jedoch abgelaufen ist, wird der Browser eine konditionale Anfrage an den entfernten Server senden. Wenn der Server angibt, dass sich die Ressource nicht geändert hat, wird sie aus dem Cache zurückgegeben. Andernfalls wird die Ressource vom Server heruntergeladen und der Cache wird aktualisiert.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage machen und den Cache mit der heruntergeladenen Ressource aktualisieren.
no-store

Der Browser ruft die Ressource vom entfernten Server ab, ohne zuerst im Cache nachzusehen, und wird den Cache nicht mit der heruntergeladenen Ressource aktualisieren.

reload

Der Browser ruft die Ressource vom entfernten Server ab, ohne zuerst im Cache nachzusehen, aber wird den Cache mit der heruntergeladenen Ressource aktualisieren.

no-cache

Der Browser sucht in seinem HTTP-Cache nach einer Antwort, die der Anfrage entspricht.

  • Wenn es eine Übereinstimmung gibt, ob frisch oder abgelaufen, wird der Browser eine konditionale Anfrage an den entfernten Server senden. Wenn der Server angibt, dass sich die Ressource nicht verändert hat, wird sie aus dem Cache zurückgegeben. Andernfalls wird die Ressource heruntergeladen und der Cache wird aktualisiert.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage machen und den Cache mit der heruntergeladenen Ressource aktualisieren.
force-cache

Der Browser sucht in seinem HTTP-Cache nach einer Antwort, die der Anfrage entspricht.

  • Wenn es eine Übereinstimmung gibt, ob frisch oder abgelaufen, wird sie aus dem Cache zurückgegeben.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage machen und den Cache mit der heruntergeladenen Ressource aktualisieren.
only-if-cached

Der Browser sucht in seinem HTTP-Cache nach einer Antwort, die der Anfrage entspricht. Experimentell

  • Wenn es eine Übereinstimmung gibt, ob frisch oder abgelaufen, wird sie aus dem Cache zurückgegeben.
  • Wenn es keine Übereinstimmung gibt, wird ein Netzwerkfehler zurückgegeben.

Der Modus "only-if-cached" kann nur verwendet werden, wenn der mode der Anfrage auf "same-origin" gesetzt ist. Zwischengespeicherte Umleitungen werden verfolgt, wenn die redirect-Eigenschaft der Anfrage auf "follow" gesetzt ist und die Umleitungen den "same-origin"-Modus nicht verletzen.

credentials Optional

Kontrolliert, ob der Browser Anmeldedaten mit der Anfrage sendet und ob irgendwelche Set-Cookie-Antwortheader beachtet werden. Anmeldedaten sind Cookies, TLS-Clientzertifikate oder Authentifizierungsheader, die einen Benutzernamen und ein Passwort enthalten. Diese Option kann einer der folgenden Werte sein:

omit

Niemals Anmeldedaten mit der Anfrage senden oder in die Antwort aufnehmen.

same-origin

Anmeldedaten nur für gleichoriginige Anfragen senden und einbeziehen.

include

Immer Anmeldedaten einbeziehen, auch für Cross-Origin-Anfragen.

Das Einbeziehen von Anmeldedaten in Cross-Origin-Anfragen kann eine Website anfällig für CSRF-Angriffe machen. Selbst wenn credentials auf include gesetzt ist, muss der Server ihrer Einbeziehung zustimmen, indem er den Access-Control-Allow-Credentials in seine Antwort aufnimmt. Darüber hinaus muss der Server in dieser Situation explizit den Ursprung des Clients im Access-Control-Allow-Origin-Antwortheader angeben (das heißt, * ist nicht erlaubt).

Siehe Einbeziehen von Anmeldedaten für weitere Details.

Standardmäßig auf same-origin.

headers Optional

Falls Sie Header zu Ihrer Anfrage hinzufügen möchten, innerhalb eines Headers-Objekts oder eines Objektliterals, dessen Schlüssel die Namen der Header und dessen Werte die Header-Werte sind.

Viele Header werden automatisch vom Browser gesetzt und können nicht durch ein Skript gesetzt werden: Diese werden verbotene Header-Namen genannt.

Wenn die mode-Option auf no-cors gesetzt ist, können Sie nur CORS-safelisted request headers setzen.

Siehe Einstellen von Headern für weitere Details.

integrity Optional

Enthält den Subresource-Integrität-Wert der Anfrage.

Dies wird überprüft, wenn die Ressource abgerufen wird, genau wie es der Fall wäre, wenn das integrity-Attribut an einem <script>-Element gesetzt wäre. Der Browser wird den Hash der abgerufenen Ressource mit dem angegebenen Algorithmus berechnen, und wenn das Ergebnis nicht mit dem angegebenen Wert übereinstimmt, wird der Browser die Fetch-Anfrage mit einem Netzwerkfehler ablehnen.

Das Format dieser Option ist <hash-algo>-<hash-source>, wobei:

  • <hash-algo> einer der folgenden Werte ist: sha256, sha384, oder sha512
  • <hash-source> die Base64-Codierung des Ergebnisses des Hashens der Ressource mit dem angegebenen Hash-Algorithmus ist.

Standardmäßig ein leerer String.

keepalive Optional

Ein Boolean. Wenn auf true gesetzt, wird der Browser die zugehörige Anfrage nicht abbrechen, wenn die Seite, die sie initiiert hat, entladen wird, bevor die Anfrage abgeschlossen ist. Dies ermöglicht eine fetch()-Anfrage als Alternative zu Navigator.sendBeacon() beim Senden von Analysen am Ende einer Sitzung zu fungieren, was einige Vorteile hat (Sie können HTTP-Methoden außer POST verwenden, Anforderungseigenschaften anpassen und auf die Antwort des Servers über die Erfüllung des Fetch Promise zugreifen). Es ist auch in Service Workers verfügbar.

Die Körpergröße für keepalive-Anfragen ist auf 64 Kibibyte begrenzt.

Standardmäßig auf false.

method Optional

Die Anfragemethode.

Standardmäßig GET.

mode Optional

Legt das Cross-Origin-Verhalten für die Anfrage fest. Einer der folgenden Werte:

same-origin

Verbietet Cross-Origin-Anfragen. Wenn eine same-origin-Anfrage an einen anderen Ursprung gesendet wird, resultiert dies in einem Netzwerkfehler.

cors

Wenn die Anfrage Cross-Origin ist, wird der Cross-Origin Resource Sharing (CORS)-Mechanismus verwendet. Nur CORS-safelisted response headers sind in der Antwort verfügbar.

no-cors

Deaktiviert CORS für Cross-Origin-Anfragen. Diese Option weist die folgenden Einschränkungen auf:

  • Die Methode darf nur HEAD, GET oder POST sein.
  • Die Header dürfen nur CORS-safelisted request headers sein, mit der zusätzlichen Einschränkung, dass der Range-Header ebenfalls nicht erlaubt ist. Dies gilt auch für alle von Service-Worker hinzugefügten Header.
  • Die Antwort ist undurchsichtig, das bedeutet, dass ihre Header und ihr Körper für JavaScript nicht verfügbar sind und ihr Statuscode immer 0 ist.

Die Hauptanwendung für no-cors ist ein Service Worker: Obwohl die Antwort auf eine no-cors-Anfrage nicht von JavaScript gelesen werden kann, kann sie von einem Service Worker zwischengespeichert und dann als Antwort auf eine abgefangene Fetch-Anfrage verwendet werden. Beachten Sie, dass Sie in dieser Situation nicht wissen, ob die Anfrage erfolgreich war oder nicht, daher sollten Sie eine Caching-Strategie anwenden, die es ermöglicht, die zwischengespeicherte Antwort aus dem Netzwerk zu aktualisieren (wie cache first with cache refresh).

Wird nur für HTML-Navigation verwendet. Eine navigate-Anfrage wird nur beim Wechsel zwischen Dokumenten erstellt.

Siehe Cross-Origin-Anfragen erstellen für weitere Details.

Standardmäßig auf cors.

priority Optional

Gibt die Priorität der Fetch-Anfrage im Verhältnis zu anderen Anfragen desselben Typs an. Muss einer der folgenden Werte sein:

high

Eine Fetch-Anfrage mit hoher Priorität im Verhältnis zu anderen Anfragen desselben Typs.

low

Eine Fetch-Anfrage mit niedriger Priorität im Verhältnis zu anderen Anfragen desselben Typs.

auto

Keine Benutzerpräferenz für die Fetch-Priorität. Es wird verwendet, wenn kein Wert gesetzt ist oder wenn ein ungültiger Wert gesetzt ist.

Standardmäßig auf auto.

redirect Optional

Bestimmt das Verhalten des Browsers, falls der Server mit einem Redirect-Status antwortet. Einer der folgenden Werte:

follow

Automatisch Redirects folgen.

error

Das Promise mit einem Netzwerkfehler ablehnen, wenn ein Redirect-Status zurückgegeben wird.

manual

Eine Antwort zurückgeben, bei der fast alle Felder gefiltert sind, um einem Service Worker zu ermöglichen, die Antwort zu speichern und später zu wiederholen.

Standardmäßig auf follow.

referrer Optional

Ein String, der den Wert angibt, der für den Referer-Header der Anfrage verwendet werden soll. Einer der folgenden Werte:

Eine gleiche Herkunft relative oder absolute URL

Setzt den Referer-Header auf den angegebenen Wert. Relative URLs werden relativ zur URL der Seite aufgelöst, die die Anfrage gemacht hat.

Ein leerer String

Den Referer-Header weglassen.

about:client

Den Referer-Header auf den Standardwert für den Kontext der Anfrage setzen (zum Beispiel die URL der Seite, die die Anfrage gemacht hat).

Standardmäßig auf about:client.

referrerPolicy Optional

Ein String, der eine Richtlinie für den Referer-Header festlegt. Die Syntax und Semantik dieser Option sind genau die gleichen wie für den Referrer-Policy-Header.

signal Optional

Ein AbortSignal. Wenn diese Option gesetzt ist, kann die Anfrage durch Aufruf von abort() am entsprechenden AbortController abgebrochen werden.

Beispiele

Übergabe von Optionen an fetch()

In diesem Beispiel übergeben wir die Optionen method, body und headers direkt in den fetch()-Methodenaufruf:

js
async function post() {
  const response = await fetch("https://example.org/post", {
    method: "POST",
    body: JSON.stringify({ username: "example" }),
    headers: {
      "Content-Type": "application/json",
    },
  });

  console.log(response.status);
}

Übergabe von Optionen an den Request()-Konstruktor

In diesem Beispiel erstellen wir ein Request, indem wir denselben Satz von Optionen in seinen Konstruktor übergeben, und übergeben dann die Anfrage an fetch():

js
async function post() {
  const request = new Request("https://example.org/post", {
    method: "POST",
    body: JSON.stringify({ username: "example" }),
    headers: {
      "Content-Type": "application/json",
    },
  });

  const response = await fetch(request);

  console.log(response.status);
}

Übergabe von Optionen an sowohl Request() als auch fetch()

In diesem Beispiel erstellen wir ein Request, indem wir die Optionen method, headers und body in seinen Konstruktor übergeben. Dann übergeben wir die Anfrage an fetch() zusammen mit den Optionen body und referrer:

js
async function post() {
  const request = new Request("https://example.org/post", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ username: "example1" }),
  });

  const response = await fetch(request, {
    body: JSON.stringify({ username: "example2" }),
    referrer: "",
  });

  console.log(response.status);
}

In diesem Fall wird die Anfrage mit den folgenden Optionen gesendet:

  • method: "POST"
  • headers: {"Content-Type": "application/json"}
  • body: '{"username":"example2"}'
  • referrer: ""

Spezifikationen

Specification
Fetch Standard
# requestinit

Siehe auch