This commit is contained in:
Ilya Kantor 2019-08-10 21:45:15 +03:00
parent 4ac9bec212
commit 2fbba39744
2 changed files with 24 additions and 15 deletions

View file

@ -32,7 +32,7 @@
<tspan x="321.866211" y="216">Access-Control-Request-Method</tspan>
<tspan x="320" y="234">Access-Control-Request-Headers</tspan>
</text>
<path id="Line" d="M541,293.5 L304,293.5 L304,291.5 L541,291.5 L541,285.5 L555,292.5 L541,299.5 L541,293.5 Z" fill="#EE6B47" fill-rule="nonzero"></path>
<path id="Line" d="M319,291.5 L556,291.5 L556,293.5 L319,293.5 L319,299.5 L305,292.5 L319,285.5 L319,291.5 Z" fill="#EE6B47" fill-rule="nonzero"></path>
<text id="200-OK" font-family="OpenSans-Regular, Open Sans" font-size="14" font-weight="normal" line-spacing="18" fill="#8A704D">
<tspan x="407" y="285">200 OK</tspan>
</text>
@ -40,7 +40,7 @@
<path id="Line-2" d="M319,501 L556,501 L556,503 L319,503 L319,509 L305,502 L319,495 L319,501 Z" fill="#EE6B47" fill-rule="nonzero"></path>
<path id="Line-3" d="M90.5,552.5 L304.5,552.5 L304.5,555.5 L90.5,555.5 L90.5,563.5 L71.5,554 L90.5,544.5 L90.5,552.5 Z" fill="#EE6B47" fill-rule="nonzero"></path>
<text id="Access-Control-Allow" font-family="OpenSans-Regular, Open Sans" font-size="14" font-weight="normal" line-spacing="18" fill="#8A704D">
<tspan x="336" y="524">Access-Control-Allow-Origin</tspan>
<tspan x="336" y="522">Access-Control-Allow-Origin</tspan>
</text>
<text id="Main-HTTP-response" font-family="OpenSans-Regular, Open Sans" font-size="14" font-weight="normal" line-spacing="18" fill="#8A704D">
<tspan x="355" y="495">Main HTTP-response</tspan>

Before

Width:  |  Height:  |  Size: 6.7 KiB

After

Width:  |  Height:  |  Size: 6.7 KiB

Before After
Before After

View file

@ -5,6 +5,12 @@ So far, we know quite a bit about `fetch`.
Let's see the rest of API, to cover all its abilities.
```smart
Please note: most of these options are used rarely. You may skip this chapter and still use `fetch` well.
Still, it's good to know what `fetch` can do, so if the need arises, you can return and read the details.
```
Here's the full list of all possible `fetch` options with their default values (alternatives in comments):
```js
@ -103,7 +109,7 @@ Here's a table with all combinations:
Let's say we have an admin zone with URL structure that shouldn't be known from outside of the site.
If we send a `fetch`, then by default it sends the `Referer` header with the full url of our page (except when we request from HTTPS to HTTP, then no `Referer`).
If we send a `fetch`, then by default it always sends the `Referer` header with the full url of our page (except when we request from HTTPS to HTTP, then no `Referer`).
E.g. `Referer: https://javascript.info/admin/secret/paths`.
@ -111,13 +117,14 @@ If we'd like other websites know only the origin part, not URL-path, we can set
```js
fetch('https://another.com/page', {
// ...
referrerPolicy: "origin-when-cross-origin" // Referer: https://javascript.info
});
```
We can put it to all `fetch` calls, maybe integrate into JavaScript library of our project that does all requests and uses `fetch` inside.
Its only difference compared to the default behavior is that for requests to another origin `fetch` only sends the origin part of the URL. For requests to our origin we still get the full `Referer` (maybe useful for debugging purposes).
Its only difference compared to the default behavior is that for requests to another origin `fetch` sends only the origin part of the URL (e.g. `https://javascript.info`, without path). For requests to our origin we still get the full `Referer` (maybe useful for debugging purposes).
```smart header="Referrer policy is not only for `fetch`"
Referrer policy, described in the [specification](https://w3c.github.io/webappsec-referrer-policy/), is not just for `fetch`, but more global.
@ -133,14 +140,14 @@ The `mode` option is a safe-guard that prevents occasional cross-origin requests
- **`"same-origin"`** -- cross-origin requests are forbidden,
- **`"no-cors"`** -- only simple cross-origin requests are allowed.
This option may be useful when the URL comes from 3rd-party, and we want a "power off switch" to limit cross-origin capabilities.
This option may be useful when the URL for `fetch` comes from a 3rd-party, and we want a "power off switch" to limit cross-origin capabilities.
## credentials
The `credentials` option specifies whether `fetch` should send cookies and HTTP-Authorization headers with the request.
- **`"same-origin"`** -- the default, don't send for cross-origin requests,
- **`"include"`** -- always send, requires `Accept-Control-Allow-Credentials` from cross-origin server,
- **`"include"`** -- always send, requires `Accept-Control-Allow-Credentials` from cross-origin server in order for JavaScript to access the response, that was covered in the chapter <info:fetch-crossorigin>,
- **`"omit"`** -- never send, even for same-origin requests.
## cache
@ -186,13 +193,13 @@ Then `fetch` will calculate SHA-256 on its own and compare it with our string. I
## keepalive
The `keepalive` option indicates that the request may outlive the page.
The `keepalive` option indicates that the request may "outlive" the webpage that initiated it.
For example, we gather statistics about how the current visitor uses our page (mouse clicks, page fragments he views), to improve user experience.
For example, we gather statistics about how the current visitor uses our page (mouse clicks, page fragments he views), to analyze and improve user experience.
When the visitor leaves our page -- we'd like to save it on our server.
When the visitor leaves our page -- we'd like to save the data at our server.
We can use `window.onunload` for that:
We can use `window.onunload` event for that:
```js run
window.onunload = function() {
@ -206,10 +213,12 @@ window.onunload = function() {
};
```
Normally, when a document is unloaded, all associated network requests are aborted. But `keepalive` option tells the browser to perform the request in background, even after it leaves the page. So it's essential for our request to succeed.
Normally, when a document is unloaded, all associated network requests are aborted. But `keepalive` option tells the browser to perform the request in background, even after it leaves the page. So this option is essential for our request to succeed.
- We can't send megabytes: the body limit for keepalive requests is 64kb.
- If we gather more data, we can send it out regularly, then there won't be a lot for the "onunload" request.
- The limit is for all currently ongoing requests. So we cheat it by creating 100 requests, each 64kb.
- We don't get the server response if the request is made `onunload`, because the document is already unloaded at that time.
It has few limitations:
- We can't send megabytes: the body limit for `keepalive` requests is 64kb.
- If gather more data, we can send it out regularly in packets, so that there won't be a lot left for the last `onunload` request.
- The limit is for all currently ongoing requests. So we can't cheat it by creating 100 requests, each 64kb.
- We can't handle the server response if the request is made in `onunload`, because the document is already unloaded at that time.
- Usually, the server sends empty response to such requests, so it's not a problem.