Načíst API

Zatím toho o fetch víme docela dost .

Podívejme se na zbytek API, abychom pokryli všechny jeho schopnosti.

Poznámka:

Poznámka:většina z těchto možností se používá zřídka. Tuto kapitolu můžete přeskočit a přesto použít fetch dobře.

Přesto je dobré vědět, co fetch můžete udělat, takže pokud to bude potřeba, můžete se vrátit a přečíst si podrobnosti.

Zde je úplný seznam všech možných fetch možnosti s jejich výchozími hodnotami (alternativy v komentářích):

let promise = fetch(url, {
  method: "GET", // POST, PUT, DELETE, etc.
  headers: {
    // the content type header value is usually auto-set
    // depending on the request body
    "Content-Type": "text/plain;charset=UTF-8"
  },
  body: undefined // string, FormData, Blob, BufferSource, or URLSearchParams
  referrer: "about:client", // or "" to send no Referer header,
  // or an url from the current origin
  referrerPolicy: "no-referrer-when-downgrade", // no-referrer, origin, same-origin...
  mode: "cors", // same-origin, no-cors
  credentials: "same-origin", // omit, include
  cache: "default", // no-store, reload, no-cache, force-cache, or only-if-cached
  redirect: "follow", // manual, error
  integrity: "", // a hash, like "sha256-abcdef1234567890"
  keepalive: false, // true
  signal: undefined, // AbortController to abort request
  window: window // null
});

Působivý seznam, že?

Plně jsme pokryli method , headers a body v kapitole Načítání.

signal možnost je zahrnuta v Načíst:Přerušit.

Nyní prozkoumáme zbývající možnosti.

referrer, referrerPolicy

Tyto možnosti určují, jak fetch nastaví HTTP Referer záhlaví.

Obvykle je tato hlavička nastavena automaticky a obsahuje adresu URL stránky, která provedla požadavek. Ve většině scénářů to není vůbec důležité, někdy z bezpečnostních důvodů má smysl jej odstranit nebo zkrátit.

Číslo referrer volba umožňuje nastavit libovolné Referer (v rámci aktuálního původu) nebo jej odstraňte.

Chcete-li odeslat žádného referrera, nastavte prázdný řetězec:

fetch('/page', {
  referrer: "" // no Referer header
});

Chcete-li nastavit jinou adresu URL v rámci aktuálního původu:

fetch('/page', {
  // assuming we're on https://javascript.info
  // we can set any Referer header, but only within the current origin
  referrer: "https://javascript.info/anotherpage"
});

Číslo referrerPolicy volba nastavuje obecná pravidla pro Referer .

Požadavky jsou rozděleny do 3 typů:

  1. Žádost na stejný zdroj.
  2. Požadavek na jiný zdroj.
  3. Požadavek z HTTPS na HTTP (z bezpečného na nebezpečný protokol).

Na rozdíl od referrer možnost, která umožňuje nastavit přesné Referer hodnota, referrerPolicy sděluje prohlížeči obecná pravidla pro každý typ požadavku.

Možné hodnoty jsou popsány ve specifikaci zásad odkazujících stránek:

  • "no-referrer-when-downgrade" – výchozí hodnota:plná Referer se vždy odesílá, pokud nepošleme požadavek z HTTPS na HTTP (na méně bezpečný protokol).
  • "no-referrer" – nikdy neposílejte Referer .
  • "origin" – odesílatel pouze v Referer , nikoli celou adresu URL stránky, např. pouze http://site.com místo http://site.com/path .
  • "origin-when-cross-origin" – zašlete celý Referer na stejný původ, ale pouze původní část pro požadavky s křížovým původem (jak je uvedeno výše).
  • "same-origin" – zašlete celý Referer do stejného původu, ale ne Referer pro cross-origin žádosti.
  • "strict-origin" – odeslat pouze původ, nikoli Referer pro požadavky HTTPS→HTTP.
  • "strict-origin-when-cross-origin" – pro stejný původ pošlete celý Referer , pro cross-origin posílejte pouze původ, pokud se nejedná o HTTPS→HTTP požadavek, pak neposílejte nic.
  • "unsafe-url" – vždy posílejte celou adresu URL v Referer , a to i pro požadavky HTTPS→HTTP.

Zde je tabulka se všemi kombinacemi:

Hodnota Na stejný původ Do jiného původu HTTPS→HTTP
"no-referrer" - - -
"no-referrer-when-downgrade" nebo "" (výchozí) plné plné -
"origin" původ původ původ
"origin-when-cross-origin" plné původ původ
"same-origin" plné - -
"strict-origin" původ původ -
"strict-origin-when-cross-origin" plné původ -
"unsafe-url" plné plné plné

Řekněme, že máme zónu pro správu se strukturou adresy URL, která by neměla být známa zvenčí webu.

Pokud odešleme fetch , pak ve výchozím nastavení vždy odešle Referer záhlaví s úplnou adresou URL naší stránky (kromě případů, kdy požadujeme z HTTPS na HTTP, pak ne Referer ).

Např. Referer: https://javascript.info/admin/secret/paths .

Pokud bychom chtěli, aby jiné webové stránky znaly pouze původní část, nikoli cestu URL, můžeme nastavit možnost:

fetch('https://another.com/page', {
  // ...
  referrerPolicy: "origin-when-cross-origin" // Referer: https://javascript.info
});

Můžeme to dát do všech fetch volání, možná integrovat do JavaScriptové knihovny našeho projektu, která provádí všechny požadavky a používá fetch uvnitř.

Jeho jediným rozdílem oproti výchozímu chování je to, že pro požadavky na jiný původ je fetch odešle pouze původní část adresy URL (např. https://javascript.info , bez cesty). Pro požadavky na náš zdroj stále dostáváme úplné Referer (možná užitečné pro účely ladění).

Zásady odkazujících stránek se nevztahují pouze na fetch

Zásady odkazujících stránek, popsané ve specifikaci, neplatí pouze pro fetch , ale globálnější.

Zejména je možné nastavit výchozí zásady pro celou stránku pomocí Referrer-Policy Hlavička HTTP nebo každý odkaz s <a rel="noreferrer"> .

režim

mode option je ochrana, která zabraňuje občasným žádostem o křížový původ:

  • "cors" – výchozí požadavky na různé zdroje jsou povoleny, jak je popsáno v části Načítání:Požadavky na různé zdroje,
  • "same-origin" – požadavky na různé zdroje jsou zakázány,
  • "no-cors" – jsou povoleny pouze požadavky na bezpečný křížový původ.

Tato možnost může být užitečná, když URL pro fetch pochází od třetí strany a my chceme „vypínač“, který omezí možnosti různých zdrojů.

přihlašovací údaje

credentials volba určuje, zda fetch by měl s požadavkem odeslat soubory cookie a hlavičky HTTP-Authorization.

  • "same-origin" – ve výchozím nastavení neposílat pro požadavky napříč původem,
  • "include" – vždy odeslat, vyžaduje Access-Control-Allow-Credentials ze serveru cross-origin, aby měl JavaScript přístup k odpovědi, která byla popsána v kapitole Fetch:Cross-Origin Requests,
  • "omit" – nikdy neposílat, a to ani v případě požadavků stejného původu.

mezipaměť

Ve výchozím nastavení fetch požadavky využívají standardní HTTP-caching. To znamená, že respektuje Expires a Cache-Control záhlaví, odešle If-Modified-Since a tak dále. Stejně jako běžné požadavky HTTP.

cache možnosti umožňují ignorovat mezipaměť HTTP nebo doladit její použití:

  • "default" fetch používá standardní HTTP-cache pravidla a hlavičky,
  • "no-store" – zcela ignorovat HTTP-cache, tento režim se stane výchozím, pokud nastavíme hlavičku If-Modified-Since , If-None-Match , If-Unmodified-Since , If-Match nebo If-Range ,
  • "reload" – nepřebírat výsledek z mezipaměti HTTP (pokud existuje), ale naplnit mezipaměť odpovědí (pokud to hlavičky odpovědí umožňují),
  • "no-cache" – vytvořit podmíněný požadavek, pokud existuje odpověď uložená v mezipaměti, a v opačném případě normální požadavek. Naplňte mezipaměť HTTP odpovědí,
  • "force-cache" – použít odpověď z mezipaměti HTTP, i když je zastaralá. Pokud v mezipaměti HTTP není žádná odpověď, proveďte běžný požadavek HTTP, chovejte se normálně
  • "only-if-cached" – použít odpověď z mezipaměti HTTP, i když je zastaralá. Pokud v mezipaměti HTTP není žádná odpověď, pak chyba. Funguje pouze při mode je "same-origin" .

přesměrování

Normálně fetch transparentně následuje přesměrování HTTP, jako je 301, 302 atd.

redirect možnost to umožňuje změnit:

  • "follow" – ve výchozím nastavení se řídí přesměrováním HTTP,
  • "error" – chyba v případě přesměrování HTTP,
  • "manual" – umožňuje ručně zpracovávat přesměrování HTTP. V případě přesměrování získáme speciální objekt odpovědi s response.type="opaqueredirect" a stav nula/prázdný a většina dalších vlastností.

integrita

integrity volba umožňuje zkontrolovat, zda odpověď odpovídá předem známému kontrolnímu součtu.

Jak je popsáno ve specifikaci, podporované hašovací funkce jsou SHA-256, SHA-384 a SHA-512, v závislosti na prohlížeči mohou být i další.

Například stahujeme soubor a víme, že jeho kontrolní součet SHA-256 je „abcdef“ (skutečný kontrolní součet je samozřejmě delší).

Můžeme to vložit do integrity možnost, jako je tato:

fetch('http://site.com/file', {
  integrity: 'sha256-abcdef'
});

Potom fetch vypočítá SHA-256 sám a porovná jej s naším řetězcem. V případě neshody dojde k chybě.

udržovat

keepalive možnost označuje, že požadavek může „přežít“ webovou stránku, která jej iniciovala.

Například shromažďujeme statistiky o tom, jak aktuální návštěvník používá naši stránku (kliknutí myší, fragmenty stránek, které si prohlíží), abychom analyzovali a zlepšili uživatelský dojem.

Když návštěvník opustí naši stránku – rádi bychom data uložili na náš server.

Můžeme použít window.onunload událost k tomu:

window.onunload = function() {
  fetch('/analytics', {
    method: 'POST',
    body: "statistics",
    keepalive: true
  });
};

Normálně, když je dokument uvolněn, jsou všechny související síťové požadavky přerušeny. Ale keepalive Tato volba říká prohlížeči, aby provedl požadavek na pozadí, i když opustí stránku. Tato možnost je tedy nezbytná pro úspěch naší žádosti.

Má několik omezení:

  • Nelze odesílat megabajty:maximální počet keepalive požadavky je 64 kB.
    • Pokud potřebujeme shromáždit velké množství statistik o návštěvě, měli bychom je pravidelně rozesílat v balíčcích, aby na posledních onunload nezbylo mnoho žádost.
    • Tento limit platí pro všechny keepalive žádosti společně. Jinými slovy, můžeme provést více keepalive požadavky paralelně, ale součet délek jejich těla by neměl přesáhnout 64 kB.
  • Pokud je dokument uvolněn, nemůžeme zpracovat odpověď serveru. Takže v našem příkladu fetch bude úspěšná díky keepalive , ale následující funkce nebudou fungovat.
    • Ve většině případů, jako je odesílání statistik, to není problém, protože server data pouze přijme a na takové požadavky obvykle odešle prázdnou odpověď.