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ů:
- Žádost na stejný zdroj.
- Požadavek na jiný zdroj.
- 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ílejteReferer
."origin"
– odesílatel pouze vReferer
, nikoli celou adresu URL stránky, např. pouzehttp://site.com
místohttp://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 neReferer
pro cross-origin žádosti."strict-origin"
– odeslat pouze původ, nikoliReferer
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 vReferer
, 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í).
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žadujeAccess-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čkuIf-Modified-Since
,If-None-Match
,If-Unmodified-Since
,If-Match
neboIf-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řimode
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 sresponse.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ícekeepalive
požadavky paralelně, ale součet délek jejich těla by neměl přesáhnout 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
- Pokud je dokument uvolněn, nemůžeme zpracovat odpověď serveru. Takže v našem příkladu
fetch
bude úspěšná díkykeepalive
, 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ěď.