Merge pull request #2390 from RapTho/patch-5

small reformulation

Author: iliakan

5-network/06-fetch-api/article.md

@@ -42,11 +42,11 @@ We fully covered `method`, `headers` and `body` in the chapter <info:fetch>.
 
 The `signal` option is covered in <info:fetch-abort>.
 
-Now let's explore the rest of capabilities.
+Now let's explore the remaining capabilities.
 
 ## referrer, referrerPolicy
 
-These options govern how `fetch` sets HTTP `Referer` header.
+These options govern how `fetch` sets the HTTP `Referer` header.
 
 Usually that header is set automatically and contains the url of the page that made the request. In most scenarios, it's not important at all, sometimes, for security purposes, it makes sense to remove or shorten it.
 
@@ -81,18 +81,18 @@ Requests are split into 3 types:
 2. Request to another origin.
 3. Request from HTTPS to HTTP (from safe to unsafe protocol).
 
-Unlike `referrer` option that allows to set the exact `Referer` value, `referrerPolicy` tells the browser general rules for each request type.
+Unlike the `referrer` option that allows to set the exact `Referer` value, `referrerPolicy` tells the browser general rules for each request type.
 
 Possible values are described in the [Referrer Policy specification](https://w3c.github.io/webappsec-referrer-policy/):
 
-- **`"no-referrer-when-downgrade"`** -- the default value: full `Referer` is sent always, unless we send a request from HTTPS to HTTP (to less secure protocol).
+- **`"no-referrer-when-downgrade"`** -- the default value: full `Referer` is always sent, unless we send a request from HTTPS to HTTP (to the less secure protocol).
 - **`"no-referrer"`** -- never send `Referer`.
 - **`"origin"`** -- only send the origin in `Referer`, not the full page URL, e.g. only `http://site.com` instead of `http://site.com/path`.
-- **`"origin-when-cross-origin"`** -- send full `Referer` to the same origin, but only the origin part for cross-origin requests (as above).
-- **`"same-origin"`** -- send full `Referer` to the same origin, but no `Referer` for cross-origin requests.
-- **`"strict-origin"`** -- send only origin, don't send `Referer` for HTTPS→HTTP requests.
-- **`"strict-origin-when-cross-origin"`** -- for same-origin send full `Referer`, for cross-origin send only origin, unless it's HTTPS→HTTP request, then send nothing.
-- **`"unsafe-url"`** -- always send full url in `Referer`, even for HTTPS→HTTP requests.
+- **`"origin-when-cross-origin"`** -- send the full `Referer` to the same origin, but only the origin part for cross-origin requests (as above).
+- **`"same-origin"`** -- send the full `Referer` to the same origin, but no `Referer` for cross-origin requests.
+- **`"strict-origin"`** -- send only the origin, not the `Referer` for HTTPS→HTTP requests.
+- **`"strict-origin-when-cross-origin"`** -- for same-origin send the full `Referer`, for cross-origin send only the origin, unless it's HTTPS→HTTP request, then send nothing.
+- **`"unsafe-url"`** -- always send the full url in `Referer`, even for HTTPS→HTTP requests.
 
 Here's a table with all combinations:
 
@@ -107,13 +107,13 @@ Here's a table with all combinations:
 | `"strict-origin-when-cross-origin"` | full | origin | - |
 | `"unsafe-url"` | full | full | full |
 
-Let's say we have an admin zone with URL structure that shouldn't be known from outside of the site.
+Let's say we have an admin zone with a URL structure that shouldn't be known from outside of the site.
 
 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`.
 
-If we'd like other websites know only the origin part, not URL-path, we can set the option:
+If we'd like other websites know only the origin part, not the URL-path, we can set the option:
 
 ```js
 fetch('https://another.com/page', {
@@ -129,7 +129,7 @@ Its only difference compared to the default behavior is that for requests to ano
 ```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.
 
-In particular, it's possible to set the default policy for the whole page using `Referrer-Policy` HTTP header, or per-link, with `<a rel="noreferrer">`.
+In particular, it's possible to set the default policy for the whole page using the `Referrer-Policy` HTTP header, or per-link, with `<a rel="noreferrer">`.
 ```
 
 ## mode
@@ -152,13 +152,13 @@ The `credentials` option specifies whether `fetch` should send cookies and HTTP-
 
 ## cache
 
-By default, `fetch` requests make use of standard HTTP-caching. That is, it honors `Expires`, `Cache-Control` headers, sends `If-Modified-Since`, and so on. Just like regular HTTP-requests do.
+By default, `fetch` requests make use of standard HTTP-caching. That is, it respects the `Expires` and `Cache-Control` headers, sends `If-Modified-Since` and so on. Just like regular HTTP-requests do.
 
 The `cache` options allows to ignore HTTP-cache or fine-tune its usage:
 
 - **`"default"`** -- `fetch` uses standard HTTP-cache rules and headers,
 - **`"no-store"`** -- totally ignore HTTP-cache, this mode becomes the default if we set a header `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match`, or `If-Range`,
-- **`"reload"`** -- don't take the result from HTTP-cache (if any), but populate cache with the response (if response headers allow),
+- **`"reload"`** -- don't take the result from HTTP-cache (if any), but populate the cache with the response (if the response headers permit this action),
 - **`"no-cache"`** -- create a conditional request if there is a cached response, and a normal request otherwise. Populate HTTP-cache with the response,
 - **`"force-cache"`** -- use a response from HTTP-cache, even if it's stale. If there's no response in HTTP-cache, make a regular HTTP-request, behave normally,
 - **`"only-if-cached"`** -- use a response from HTTP-cache, even if it's stale. If there's no response in HTTP-cache, then error. Only works when `mode` is `"same-origin"`.
@@ -177,7 +177,7 @@ The `redirect` option allows to change that:
 
 The `integrity` option allows to check if the response matches the known-ahead checksum.
 
-As described in the [specification](https://w3c.github.io/webappsec-subresource-integrity/), supported hash-functions are SHA-256, SHA-384, and SHA-512, there might be others depending on a browser.
+As described in the [specification](https://w3c.github.io/webappsec-subresource-integrity/), supported hash-functions are SHA-256, SHA-384, and SHA-512, there might be others depending on the browser.
 
 For example, we're downloading a file, and we know that it's SHA-256 checksum is "abcdef" (a real checksum is longer, of course).
 
@@ -195,11 +195,11 @@ Then `fetch` will calculate SHA-256 on its own and compare it with our string. I
 
 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 analyze and improve user experience.
+For example, we gather statistics on how the current visitor uses our page (mouse clicks, page fragments he views), to analyze and improve the user experience.
 
-When the visitor leaves our page -- we'd like to save the data at our server.
+When the visitor leaves our page -- we'd like to save the data to our server.
 
-We can use `window.onunload` event for that:
+We can use the `window.onunload` event for that:
 
 ```js run
 window.onunload = function() {
@@ -213,12 +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 this option is essential for our request to succeed.
+Normally, when a document is unloaded, all associated network requests are aborted. But the `keepalive` option tells the browser to perform the request in the background, even after it leaves the page. So this option is essential for our request to succeed.
 
 It has a few limitations:
 
 - We can't send megabytes: the body limit for `keepalive` requests is 64KB.
     - If we need to gather a lot of statistics about the visit, we should send it out regularly in packets, so that there won't be a lot left for the last `onunload` request.
     - This limit applies to all `keepalive` requests together. In other words, we can perform multiple `keepalive` requests in parallel, but the sum of their body lengths should not exceed 64KB.
 - We can't handle the server response if the document is unloaded. So in our example `fetch` will succeed due to `keepalive`, but subsequent functions won't work.
-    - In most cases, such as sending out statistics, it's not a problem, as server just accepts the data and usually sends an empty response to such requests.
+    - In most cases, such as sending out statistics, it's not a problem, as the server just accepts the data and usually sends an empty response to such requests.