PARAMETERS.md

referrer, referrerPolicy

These options govern how fetch sets 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.

The referrer option allows to set any Referer within the current origin or remove it.

To send no referer, set an empty string:

nfetch.get('/page', {
*!*
  referrer: "" // no Referer header
*/!*
});

To set another url within the current origin:

nfetch.get('/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"
*/!*
});

The referrerPolicy option sets general rules for Referer.

Requests are split into 3 types:

1. Request to the same origin.
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.

Possible values are described in the Referrer Policy specification:

• "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" -- 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 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.

mode

The mode option is a safe-guard that prevents occasional cross-origin requests:

• "cors" -- the default, cross-origin requests are allowed, as described in info:fetch-crossorigin,
• "same-origin" -- cross-origin requests are forbidden,
• "no-cors" -- only simple cross-origin requests are allowed.

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

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.

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),
• "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".

redirect

Normally, fetch transparently follows HTTP-redirects, like 301, 302 etc.

The redirect option allows to change that:

• "follow" -- the default, follow HTTP-redirects,
• "error" -- error in case of HTTP-redirect,
• "manual" -- don't follow HTTP-redirect, but response.url will be the new URL, and response.redirected will be true, so that we can perform the redirect manually to the new URL (if needed).

integrity

The integrity option allows to check if the response matches the known-ahead checksum.

As described in the specification, supported hash-functions are SHA-256, SHA-384, and SHA-512, there might be others depending on a 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).

We can put it in the integrity option, like this:

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

Then fetch will calculate SHA-256 on its own and compare it with our string. In case of a mismatch, an error is triggered.

keepalive

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.

When the visitor leaves our page -- we'd like to save the data at our server.

We can use window.onunload event for that:

window.onunload = () => {
  const anyObj = {
    important: 'start this project if liked'
  }

  new nfetch().post('/analytics', anyObj, { keepalive: true });
};

Source of article