RequestInit

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

Man kann ein RequestInit-Objekt in den Request() Konstruktor oder direkt in den Aufruf der fetch() Funktion übergeben.

Es ist auch möglich, ein Request mit einem RequestInit zu konstruieren und das Request zusammen mit einem weiteren RequestInit an einen fetch() Aufruf zu übergeben. Falls Sie dies tun und die gleiche Option an beiden Stellen gesetzt ist, wird der Wert verwendet, der direkt an fetch() übergeben wird.

Instanz-Eigenschaften

attributionReporting Optional Experimentell

Zeigt an, dass Sie möchten, dass die Antwort der Anfrage eine JavaScript-basierte Attributionsquelle oder einen Attributionstrigger registrieren kann. attributionReporting ist ein Objekt, das die folgenden Eigenschaften enthält:

eventSourceEligible

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

triggerEligible

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

Siehe die Attribution Reporting API für mehr Details.

body Optional

Der Anfragekörper enthält Inhalte, die an den Server gesendet werden sollen, beispielsweise in einer POST oder PUT Anfrage. Er wird als Instanz eines der folgenden Typen angegeben:

Siehe Festlegen eines Körpers für mehr 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 Verwendung der Topics API für mehr 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, aber sie abgelaufen ist, wird der Browser eine bedingte Anfrage an den entfernten Server stellen. Wenn der Server anzeigt, 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 aktualisiert.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage stellen 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 dann 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, frisch oder abgelaufen, wird der Browser eine bedingte Anfrage an den entfernten Server stellen. Wenn der Server anzeigt, 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 aktualisiert.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage stellen 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, frisch oder abgelaufen, wird sie aus dem Cache zurückgegeben.
  • Wenn es keine Übereinstimmung gibt, wird der Browser eine normale Anfrage stellen 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, frisch oder abgelaufen, wird sie aus dem Cache zurückgegeben.
  • Wenn es keine Übereinstimmung gibt, wird ein Netzwerkfehler zurückgegeben.

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

credentials Optional

Steuert, ob der Browser Anmeldeinformationen mit der Anfrage sendet und ob Set-Cookie Antwort-Header berücksichtigt werden. Anmeldeinformationen sind Cookies, TLS Client-Zertifikate oder Authentifizierungs-Header, die einen Benutzernamen und ein Passwort enthalten. Diese Option kann einen der folgenden Werte haben:

omit

Senden Sie niemals Anmeldeinformationen in der Anfrage oder schließen Sie Anmeldeinformationen in der Antwort ein.

same-origin

Senden und schließen Sie Anmeldeinformationen nur für same-origin Anfragen ein.

include

Schließen Sie Anmeldeinformationen immer ein, auch für Cross-Origin-Anfragen.

Das Einbeziehen von Anmeldeinformationen bei Cross-Origin-Anfragen kann eine Website anfällig für CSRF Angriffe machen, daher muss auch dann, wenn credentials auf include gesetzt ist, der Server ihrer Einbeziehung durch die Aufnahme des Access-Control-Allow-Credentials in seine Antwort zustimmen. Zusätzlich muss der Server in diesem Fall explizit den Herkunftsort des Clients im Access-Control-Allow-Origin Antwort-Header angeben (das heißt, * ist nicht erlaubt).

Weitere Informationen finden Sie unter Einbeziehen von Anmeldeinformationen.

Standardmäßig auf same-origin.

headers Optional

Alle Header, die Sie Ihrer Anfrage hinzufügen möchten, enthalten sich in einem Headers Objekt oder in einem Objektliteral, 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 als verbotene Anforderungsheader bezeichnet.

Wenn die mode Option auf no-cors gesetzt ist, können Sie nur CORS-sichere Anforderungsheader setzen.

Siehe Setzen von Headern für mehr Details.

integrity Optional

Enthält den Subressourcen-Integritäts Wert der Anfrage.

Dies wird überprüft, wenn die Ressource abgerufen wird, genauso wie es überprüft wird, wenn das integrity Attribut an einem <script> Element gesetzt ist. Der Browser wird den Hash der abgerufenen Ressource mit dem angegebenen Algorithmus berechnen, und wenn das Ergebnis nicht mit dem angegebenen Wert übereinstimmt, wird die Anfrage mit einem Netzwerkfehler abgelehnt.

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

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

Standardmäßig auf einen leeren String gesetzt.

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 einer fetch() Anfrage, Analytik am Ende einer Sitzung zu senden, selbst wenn der Benutzer die Seite verlässt oder schließt.

Dies hat einige Vorteile gegenüber der Verwendung von Navigator.sendBeacon() für denselben Zweck. Zum Beispiel können Sie HTTP-Methoden verwenden, die nicht POST sind, Anfrage-Eigenschaften anpassen und auf die Serverantwort über die Fulfillment des Fetch Promise zugreifen. Es ist auch in Service-Workern verfügbar.

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

Standardmäßig auf false.

method Optional

Die Anfragemethode.

Standardmäßig auf GET.

mode Optional

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

same-origin

Erlaubt keine Cross-Origin-Anfragen. Wenn eine same-origin Anfrage an eine andere Herkunft gesendet wird, ist das Ergebnis ein Netzwerkfehler.

cors

Wenn die Anfrage Cross-Origin ist, wird der Cross-Origin Resource Sharing (CORS) Mechanismus verwendet. Nur CORS-sichere Antwort-Header werden in der Antwort offengelegt.

no-cors

Deaktiviert CORS für Cross-Origin-Anfragen. Diese Option bringt die folgenden Einschränkungen mit sich:

  • Die Methode darf nur HEAD, GET oder POST sein.
  • Die Header dürfen nur CORS-sichere Anforderungsheader sein, mit der zusätzlichen Einschränkung, dass der Range Header ebenfalls nicht erlaubt ist. Dies gilt auch für alle Header, die von Service-Workern hinzugefügt werden.
  • Die Antwort ist opaqu, was 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 für einen Service-Worker: Auch wenn die Antwort auf eine no-cors Anfrage von JavaScript nicht gelesen werden kann, kann sie von einem Service-Worker zwischengespeichert werden 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 Cache-Strategie annehmen, die es ermöglicht, die zwischengespeicherte Antwort aus dem Netzwerk zu aktualisieren (zum Beispiel cache first mit cache refresh).

Wird nur von der HTML-Navigation verwendet. Eine navigate Anfrage wird nur während des Wechsels zwischen Dokumenten erstellt.

Siehe Creating cross-origin requests für mehr 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 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. 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 im Fall, dass der Server mit einem Weiterleitungsstatus antwortet. Einer der folgenden Werte:

follow

Automatisch Weiterleitungen folgen.

error

Das Versprechen mit einem Netzwerkfehler ablehnen, wenn ein Weiterleitungsstatus zurückgegeben wird.

manual

Eine Antwort mit fast allen ausgefilterten Feldern zurückgeben, um einem Service-Worker zu ermöglichen, die Antwort zu speichern und später erneut auszuführen.

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:

Eine same-origin relative oder absolute URL

Setzen Sie 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

Setzen Sie den Referer Header auf den Standardwert für den Kontext der Anfrage (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 dieselben wie für den Referrer-Policy Header.

signal Optional

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

Beispiele

Optionen an fetch() übergeben

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);
}

Optionen in den Request() Konstruktor übergeben

In diesem Beispiel erstellen wir eine Request, indem wir den gleichen Satz von Optionen in seinen Konstruktor übergeben, und geben dann die Anfrage an fetch() weiter:

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);
}

Optionen sowohl in Request() als auch in fetch() übergeben

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

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
# requestinit

Siehe auch