Fetch

Living Standard — Last Updated 24 April 2014

This Version:
http://fetch.spec.whatwg.org/
Participate:
Send feedback to whatwg@whatwg.org or file a bug (open bugs)
IRC: #whatwg on Freenode
Version History:
https://github.com/whatwg/fetch/commits
Editor:
Anne van Kesteren (Mozilla) <annevk@annevk.nl>

Abstract

The Fetch standard defines requests, responses, and the process that binds them; fetching.

Table of Contents

  1. Goals
  2. 1 Conformance
  3. 2 Terminology
    1. 2.1 HTTP
    2. 2.2 Requests
    3. 2.3 Responses
  4. 3 HTTP extensions
    1. 3.1 HTTP Origin header
    2. 3.2 HTTP CORS protocol
      1. 3.2.1 General
      2. 3.2.2 HTTP requests
      3. 3.2.3 HTTP responses
      4. 3.2.4 HTTP new header syntax
  5. 4 Fetching
    1. 4.1 Basic fetch
    2. 4.2 CORS fetch with preflight
    3. 4.3 CORS preflight fetch
    4. 4.4 CORS preflight cache
    5. 4.5 CORS check
  6. HTML fetch
  7. References
  8. Acknowledgments

Goals

To unify fetching across the web platform this specification supplants a number of algorithms and specifications:

Unifying fetching provides consistent handling of:

In due course, it should also help clarify the semantics of CSP and provide a model to hook offline networking into.

1 Conformance

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this specification are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

2 Terminology

This specification uses terminology from the Encoding and URL Standards. [ENCODING] [URL]

A byte sequence with bytes in the range 0x00 to 0x7F is represented as a utf-8 encoded string with code points in the range U+0000 to U+007F. To avoid confusion with an actual string backticks are used.

"true" is a string, while `true` is a byte sequence.

Comparing two byte sequences in a byte case-insensitive manner means comparing them exactly, byte for byte, except that the bytes in the range 0x41 to 0x5A are considered to also match their corresponding byte in the range 0x61 to 0x7A.

A case-insensitive byte sequence is a byte sequence that when compared to another byte sequence does so in a byte case-insensitive manner.

The case-insensitive byte sequences `Content-Type` and `content-TYPE` are equal.

2.1 HTTP

While fetching encompasses more than just HTTP, it borrows a number of concepts from HTTP and applies these to resources obtained via other means (e.g. via data URL).

A method is a byte sequence.

A header consists of a name and value. A name is a case-insensitive byte sequence and a value is a byte sequence.

A simple method is a method that is `GET`, `HEAD`, or `POST`.

A simple header is a header whose name is `Accept`, `Accept-Language`, or `Content-Language`, or whose name is `Content-Type` and value, once parsed, is `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain`.

What we never resolved in CORS was whether only certain parameters should be allowed and how exactly the MIME type parsing would work. Hopefully parsing MIME types will solve this.

To parse a header value parse it per the ABNF and return the values obtained for the given name, and return failure if the value did not match the ABNF.

2.2 Requests

The input to fetch is a request.

A request has an associated method. Unless stated otherwise a request's method is `GET`.

A request has an associated url (a URL).

A request has associated author headers and headers. Unless stated otherwise request's author headers and headers are empty lists of headers.

A request has an associated body. Unless stated otherwise a request's body is null.


A request has an associated client (a JavaScript global environment).

A request has an associated context, which is one of child, connect, font, form, image, media, navigate, object, popup, script, sharedworker, style, and worker.

These will be used for upcoming CSP and service worker integration.

A client request is a request whose context is one of child, navigate, popup, and sharedworker.

A resource request is a request that is not a client request.

The following table illustrates the relationship between request contexts and CSP directives:

request contexts CSP directive Platform feature example
child child-src HTML's iframe element
connect connect-src XMLHttpRequest
font font-src CSS' @font-face
form form-action HTML's form element
image img-src SVG's image element
media media-src HTML's track element
navigate The result of clicking HTML's a element
object object-src HTML's embed element
popup window.open()
script script-src HTML's script element
sharedworker child-src SharedWorker
style style-src HTML's link element when its rel attribute is set to "stylesheet"
worker child-src Worker

A request has an associated origin, and force Origin header flag. Unless stated otherwise a request's origin is null and its force Origin header flag is unset.

A request has an associated referrer. Unless stated otherwise it is null.

A request has an associated synchronous flag. Unless stated otherwise a request's synchronous flag is unset.

A request has an associated mode, which is one of same-origin, tainted cross-origin, CORS, and CORS-with-forced-preflight. Unless stated otherwise, request's mode is tainted cross-origin.

A request has an associated omit credentials mode, which is one of always, CORS, and never.

I think we want the default to become always, but currently it is never.

A request has an associated use URL credentials flag. Unless stated otherwise, it is unset.

A request has an associated manual redirect flag. Unless stated otherwise, it is unset.


A request has an associated redirect count. Unless stated otherwise, it is zero.

A request has an associated response tainting, which is one of basic, CORS, and opaque. Unless stated otherwise, it is basic.

A request's redirect count and response tainting are used as bookkeeping details by the fetch algorithm.


Fetch end points must enforce restrictions on a request's method and author headers.

The forbidden methods are methods that are a byte case-insensitive match for `CONNECT`, `TRACE`, and `TRACK`. [HTTPVERBSEC]

The forbidden author header names are all these header names:

… and header names that start with `Proxy-` or `Sec-` (including when it is just `Proxy-` or `Sec-`).

These are forbidden so the user agent remains in full control over them. Names starting with `Sec-` are not allowed to be set to allow new headers to be minted that are guaranteed not to come from fetching end points that allow control over headers by authors, such as XMLHttpRequest. [XHR]

2.3 Responses

The result of fetch is a response. A response evolves over time. That is, not all its fields are available straight away.

A response has an associated type which is one of default, redirect, and error. Unless stated otherwise, it is default.

A response can have an associated termination reason which is one of end-user abort, fatal, and timeout.

A response has an associated url, status, status message, headers, and a body. Unless stated otherwise, a response's url is null, status is 200, status message is `OK`, headers is an empty list, and body is null.


A response whose type is error is known as a network error.

A network error's status is 0 and its status message is the empty byte sequence.

A response whose type is redirect is known as a redirect.


A filtered response is a limited view on a response. This response is referred to as the filtered response's associated internal response.

The fetch algorithm returns such a view to ensure APIs do not accidentally leak information. If the information is required, e.g. to feed image data to a decoder, the associated internal response can be used.

A basic filtered response is a filtered responses whose response headers exclude any headers in internal response's response headers whose name is `Set-Cookie` or `Set-Cookie2`.

A CORS filtered responses is a filtered responses whose response headers exclude all headers in internal response's response headers, except those whose name is either one of `Cache-Control`, `Content-Language`, `Content-Type`, `Expires`, `Last-Modified`, and `Pragma`, and except those whose name is one of the values of the parsed value of the header in internal response's response headers whose name is `Access-Control-Expose-Headers`.

An opaque filtered responses is a filtered responses whose type is error, status is 0, status message is the empty byte sequence, headers is an empty list, and body is null.

In other words, an opaque filtered response is indistinguishable from a network error. When introducing new APIs, do not use the internal response as you will leak information.

3 HTTP extensions

3.1 HTTP Origin header

The `Origin` request header indicates where a fetch originates from.

The `Origin` header is a stripped-down version of the `Referer` [sic] header as to not reveal confidential path information. It is used for all basic fetches whose CORS flag is set as well as fetches where request's method is `POST`. Due to compatibility constraints it is not included in all fetches.

Its value ABNF:

Origin                           = origin-or-null

origin-or-null                   = origin / %x6E.75.6C.6C ; "null", case-sensitive
origin                           = scheme "://" host [ ":" port ]

This replaces the syntax defined for the `Origin` header by The Web Origin Concept. Unfortunately that document cannot be updated to match reality without involving layers and layers of bureaucracy. [ORIGIN]

3.2 HTTP CORS protocol

To allow sharing resources cross-origin and allow for more versatile HTTP requests than possible with HTML's form element, the platform has a CORS protocol layered on top of HTTP. It allows resources to declare they can be shared with resources residing on a different origin.

It needs to be an opt-in mechanism to prevent leaking data from resources behind a firewall (intranets). Additionally, for credentialed HTTP requests it needs to be opt-in to prevent leaking potentially-sensitive data.

This section explains the CORS protocol as it pertains to servers. Requirements for user agents are part of the fetch algorithm.

3.2.1 General

The CORS protocol consists of a set of headers that indicates whether a particular resource can be shared cross-origin.

For HTTP requests that are more involved than what is possible with HTML's form element, a CORS preflight fetch is performed, to ensure the resource understands the CORS protocol.

3.2.2 HTTP requests

An HTTP request can be identified as pertaining in the CORS protocol if it includes an `Origin` header. This is named a CORS request.

An HTTP request can be identified as being a check to see if the CORS protocol is understood if it is a CORS request, uses `OPTIONS` as method, and includes these headers:

`Access-Control-Request-Method`

Indicates which method a future CORS request to the same resource might use.

`Access-Control-Request-Headers`

Indicates which headers a future CORS request to the same resource might use.

This is named a CORS preflight request.

3.2.3 HTTP responses

An HTTP response to a CORS request can include the following headers:

`Access-Control-Allow-Origin`

Indicates whether a resource can be shared, via returning the literal value of the Origin request header (which can be `null`) or `*` in a response.

`Access-Control-Allow-Credentials`

Indicates whether a resource can be shared when request's omit credentials mode is never.

For a CORS preflight request, request's omit credentials mode is always never, but for any subsequent CORS requests it might not be. Support therefore needs to be indicated as part of the HTTP response to the CORS preflight request as well.

An HTTP response to a CORS preflight request can include the following headers:

`Access-Control-Allow-Methods`

Indicates which methods are supported by the resource for the purposes of the CORS protocol.

The `Allow` header is not relevant for the purposes of the CORS protocol.

`Access-Control-Allow-Headers`

Indicates which headers are supported by the resource for the purposes of the CORS protocol.

`Access-Control-Max-Age`

Indicates how long the information provided by the `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` headers can be cached.

An HTTP response to a CORS request that is not a CORS preflight request can also include the following header:

`Access-Control-Expose-Headers`

Indicates which headers can be exposed as part of the HTTP response, via listing their names.

3.2.4 HTTP new header syntax

ABNF for the values of the headers used by the CORS protocol:

Access-Control-Request-Method    = Method
Access-Control-Request-Headers   = #field-name

Access-Control-Allow-Origin      = origin-or-null / "*"
Access-Control-Allow-Credentials = %x74.72.75.65 ; "true", case-sensitive
Access-Control-Expose-Headers    = #field-name
Access-Control-Max-Age           = delta-seconds
Access-Control-Allow-Methods     = #Method
Access-Control-Allow-Headers     = #field-name

4 Fetching

The algorithm below defines fetching. In broad strokes, it takes a request and outputs a response.

That is, it either returns a response if request's synchronous flag is set, or it queues tasks annotated process response, process response body, and process response end-of-file for the response on the networking task source.

To capture uploads, if request's synchronous flag is unset, tasks annotated process request body and process request end-of-file for the request can be queued on the networking task source.

To perform a fetch using request, optionally with a CORS flag, run the steps below. An ongoing fetch can be terminated with reason reason, which must be one of end-user abort, fatal, or timeout.

The CORS flag is an internal manner for handling redirects. Only use the request parameter in other standards.

  1. Modify request's url per HTTP Strict Transport Security, if applicable. [HSTS]

  2. Invoke CSP hook with request's url, context, and client.

  3. Let url be request's url.

  4. Let origin be request's origin.

  5. If request's synchronous flag is unset and fetch is not invoked recursively, run the remaining steps asynchronously.

  6. Let response be the value corresponding to the first matching statement:

    url's origin is origin and the CORS flag is unset
    url's scheme is one of "about", "blob", and "data", and request's redirect count is zero

    The result of performing a basic fetch using request.

    request's mode is same-origin

    A network error.

    request's mode is tainted cross-origin

    Set request's response tainting to opaque.

    The result of performing a basic fetch using request.

    url's scheme is not one of "http" and "https"

    A network error.

    request's mode is CORS-with-forced-preflight
    request's method is not a simple method
    A header in request's author headers is not a simple header

    Set request's response tainting to CORS.

    The result of performing a CORS fetch with preflight using request.

    Otherwise

    Set request's response tainting to CORS.

    The result of performing a basic fetch using request with the CORS flag set.

  7. If fetch is invoked recursively, return response.

  8. Set response's url to request's url.

  9. Set response to the following filtered response with response as its internal response, depending on request's response tainting:

    basic
    basic filtered response
    CORS
    CORS filtered response
    opaque
    opaque filtered response
  10. If request's synchronous flag is set, wait for either response to have been fully transmitted or response to have a termination reason, and then return it.

  11. Otherwise, run these substeps:

    1. Queue a task to process response for response.

    2. If response is a network error, terminate this algorithm. No point in continuing.

    3. Then, either once response's body is at least one byte long or there is no response's body, queue a task to process response body for response. Keep queuing tasks to process response body for response every 50ms or for each byte of response's body transmitted, whichever is least frequent, while response has no termination reason.

    4. Then, once response's body is fully transmitted or has a termination reason, queue a task to process response end-of-file for response.

      This specification does not define what "fully transmitted" means. Ideally FTP/HTTP define this in detail, including when e.g. `Content-Length` is not supplied or is deemed faulty.

    Use the networking task source for these tasks.

4.1 Basic fetch

To perform a basic fetch using request, with an optional CORS flag and HTTP authentication flag, switch on request's url's scheme and run the associated steps:

"about"

If request's url's scheme data is "blank", return a response whose headers consist of a single header whose name is `Content-Type` and value is `text/html;charset=utf-8`, and body is the empty byte sequence.

Otherwise, return a network error.

URLs such as "about:config" are handled during navigation and result in a network error in the context of fetching.

"blob"

It has been argued this should be handled outside of fetching.

"data"

If request's method is `GET` and obtaining a resource from request's url does not return failure, return a response whose headers consist of a single header whose name is `Content-Type` and value is the MIME type and parameters returned from obtaining a resource, and body is the data returned from obtaining a resource.

Otherwise, return a network error.

"file"
"ftp"

For now, unfortunate as it is, file and ftp URLs are left as an exercise for the reader.

When in doubt, return a network error.

"http"
"https"

Make an HTTP request following the requirements from HTTP and TLS as appropriate, with these additional constraints:

  1. Set the HTTP request method to request's method.

    Forbidden methods are not supposed to reach this point.

  2. If request's referrer is not null, include a `Referer` header whose value is request's referrer.

    User agents are encouraged to provide the end user with options to always exclude `Referer` headers or have it expose less sensitive information.

  3. If request's force Origin header flag is set, include an `Origin` header whose value is request's origin, serialized to a byte sequence.

  4. Include all of request's headers and let them replace any headers with the same name already present in the HTTP request.

  5. Include all of request's author headers as long as their name is not already present in the HTTP request.

    Forbidden author header names are not supposed to reach this point.

  6. If request's omit credentials mode is never or request's omit credentials mode is CORS and the CORS flag is unset, run these substeps:

    1. Include `Cookie` headers associated with request's url. [COOKIES]

    2. If there's an authentication entry for request's url and either request's use URL credentials flag is unset or request's url does not include credentials, include the Authorization header from the authentication entry.

    3. Otherwise, if request's url includes credentials, and the HTTP authentication flag is set, include an Authorization header using those credentials.

  7. If there's a proxy authentication entry, use it as appropriate. [HTTP]

    This intentionally does not depend on request's omit credentials mode.

  8. If request's body is non-null, include it, and queue a task every 50ms or for each byte of request's body transmitted, whichever is least request, to process request body for request.

    If included, when request's body is fully transmitted (and the HTTP request has not been observably terminated yet), queue a task to process request end-of-file for request.

    Use the networking task source.

If the HTTP request is terminated before all headers from the resource are obtained, return a network error. If this is due to fetch being terminated with reason reason, set the return value's termination reason to reason.

Otherwise, when the headers from the resource are obtained, let response be a new response and set its fields appropriately.

If there are cookies to be set and either request's omit credentials mode is never, or request's omit credentials mode is CORS and the CORS flag is unset, run these steps:

  1. Wait until ownership of the storage mutex can be taken by this instance of the fetch algorithm.

  2. Take ownership of the storage mutex.

  3. Update the cookies. [COOKIES]

    This is a fingerprinting vector.

  4. Release the storage mutex so that it is once again free.

If the CORS flag is set and a CORS check for request and response returns failure, return a network error.

If response's status is 304, run these steps:

  1. For responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow a request's author headers to override automatic cache validation (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through.

Otherwise, if response's status is 301, 302, 303, 307, or 308, run these steps:

  1. If response's headers do not contain a header whose name is `Location`, return response.

  2. If response's headers contain more than one header whose name is `Location`, return a network error.

  3. Let location be the value of the header whose name is `Location` within response's headers.

  4. Let locationURL be the result of parsing location with request's url.

  5. If locationURL is failure, return a network error.

  6. If request's redirect count is twenty, return a network error.

  7. Increase request's redirect count by one.

  8. Set response's type to redirect.

  9. If request's manual redirect flag is unset, run these substeps:

    1. If the CORS flag is set and locationURL's origin is not request's url's origin, set request's origin to a globally unique identifier.

    2. If the CORS flag is set and locationURL's username or password is non-null, return a network error.

    3. Set request's url to locationURL.

    4. Return the result of performing a fetch using request, with the CORS flag set if set.

Otherwise, if response's status is 401, run these steps:

  1. If the CORS flag is set, return response.

  2. Needs testing: multiple WWW-Authenticate headers, missing, parsing issues.

  3. If request's use URL credentials flag is unset, or the HTTP authentication flag is set, run these substeps:

    1. Prompt the end user for a username and password.

    2. Set request's url's username and password to the given values.

  4. Return the result of performing a basic fetch using request, with the HTTP authentication flag set.

Otherwise, if response's status is 407, run these steps:

  1. Needs testing: multiple Proxy-Authenticate headers, missing, parsing issues.

  2. Prompt the end user as appropriate and store the result as appropriate as a proxy authentication entry. [HTTP]

    Remaining details surrounding proxy authentication are defined by HTTP.

  3. Return the result of performing basic fetch using request.

If the HTTP authentication flag is set, create an authentication entry for request's url and the given realm. [HTTPAUTH]

Return response, but continue with the request and growing response's body. If at any point fetch is terminated with reason reason, set response's termination reason to reason. This modifies response after it has been returned. Logic in fetch takes care of the rest.

Otherwise

Return a network error.

4.2 CORS fetch with preflight

To perform a CORS fetch with preflight using request, run these steps:

  1. If

    then run these substeps:

    1. Let response be a CORS preflight fetch using request.

    2. If response is a network error, return response.

  2. Set request's manual redirect flag.

  3. Let response be a basic fetch using request with the CORS flag set.

  4. If response is a redirect, set its type to error.

  5. If response is a network error, clear cache entries using request.

  6. Return response.

4.3 CORS preflight fetch

To perform a CORS preflight fetch using request, run these steps:

  1. Let preflight be a new request.

  2. Set preflight's url to request's url.

  3. Set preflight's origin to request's origin.

  4. Set preflight's referrer to request's referrer.

  5. Set preflight's method to `OPTIONS`.

  6. Append a header named `Access-Control-Request-Method` with value request's method to preflight's headers.

  7. Let headers be the names of request's author headers, sorted lexicographically and byte lowercased.

  8. Let header value be the items in headers separated from each other by 0x2C 0x20.

  9. Append a header named `Access-Control-Request-Headers` with value header value to preflight's headers.

  10. Set preflight's manual redirect flag.

  11. Let response be the result of performing a basic fetch using preflight with the CORS flag set.

  12. If response's status is in the range 200 to 299, run these substeps:

    1. Let methods be the result of parsing all response's headers' named `Access-Control-Allow-Methods`.

    2. Let header names be the result of parsing all response's headers' named `Access-Control-Allow-Headers`.

    3. If either methods or header names is failure, return a network error.

    4. If methods is empty and request's mode is CORS-with-forced-preflight, append request's method to methods.

      This ensures that a CORS preflight fetch that happened due to request's mode being CORS-with-forced-preflight is cached.

    5. If request's method is not in methods and is not a simple method, return failure.

    6. If one of request's headers' names is not in header names or its corresponding header is not a simple header, return a network error.

    7. Let max-age be the result of parsing all response's headers' named `Access-Control-Max-Age`.

    8. If max-age is failure, set max-age to zero.

    9. If max-age is greater than an imposed limit on max-age, set max-age to the imposed limit.

    10. If the user agent does not provide for a cache, return response.

    11. For each method in methods for which there is a method cache match using request, set matching entry's max-age to max-age.

    12. For each method in methods for which there is no method cache match using request, create a new entry in CORS preflight cache as follows:

      origin
      request's origin
      url
      request's url
      max-age
      max-age
      credentials
      False if request's omit credentials mode is not never, and true otherwise
      method
      method
    13. For each header name in header names for which there is a header name cache match using request, set matching entry's max-age to max-age.

    14. For each header name in header names for which there is no header name cache match using request, create a new entry in CORS preflight cache as follows:

      origin
      request's origin
      url
      request's url
      max-age
      max-age
      credentials
      False if request's omit credentials mode is not never, and true otherwise
      header name
      header name
    15. Return response.

  13. Otherwise, return a network error.

4.4 CORS preflight cache

A CORS preflight cache consists of a collection of entries where each entry has these fields: origin, url, max-age, credentials, method, and header name.

Entries must be removed after the seconds specified in the max-age field have passed since storing the entry. Entries may be removed before that moment arrives.

To clear cache entries given a request, remove any entries in the CORS preflight cache whose origin is request's origin and whose url is request's url.

There is a cache match for request if origin is request's origin, url is request's url, and either credentials is false and request's omit credentials mode is not never or credentials is true and request's omit credentials mode is never.

There is a method cache match for method using request when there is an entry in CORS preflight cache for which there is a cache match for request and its method is method.

There is a header name cache match for headerName using request when there is an entry in CORS preflight cache for which there is a cache match for request and its header name is headerName.

4.5 CORS check

To perform a CORS check for a request and response, run these steps:

  1. If response's headers contains zero or more than one header whose name is `Access-Control-Allow-Origin`, return failure.

  2. Let result be the value of the header whose name is `Access-Control-Allow-Origin` within response's headers.

  3. If request's omit credentials mode is not never and result is `*`, return success.

  4. If request's origin serialized to a byte sequence is not result, return failure.

  5. If request's omit credentials mode is not never, return success.

  6. If response's headers contains zero or more than one header whose name is `Access-Control-Allow-Credentials`, return failure.

  7. If the value of the header whose name is `Access-Control-Allow-Credentials` within response's headers is `true`, return success.

  8. Return failure.

HTML fetch

HTML defines two algorithms for obtaining resources. To ease transitioning towards this specification, a temporary mapping is defined between these "legacy" algorithms and fetch.

When a user agent is to fetch a resource or URL, optionally from an origin origin, optionally using a specific referrer source referrer source, and optionally with any of a synchronous flag, a manual redirect flag, a force same-origin flag, and a block cookies flag, the following steps must be run:

The block cookies flag is obsolete now.

  1. If the Document with which any tasks queued by this algorithm would be associated doesn't have an associated browsing context, then terminate these steps.

  2. Let req be a new request.

  3. If this algorithm was invoked with "from an origin", set req's origin to origin.

  4. Set req's referrer to the result of determining referrer using referrer source (if given).

  5. Set req's mode to same-origin if the force same-origin flag is set, and to tainted cross-origin otherwise.

  6. Set req's manual redirect flag if manual redirect flag is set.

  7. Set req's synchronous flag if synchronous flag is set.

  8. fetch req.

When the user agent is required to perform a potentially CORS-enabled fetch of an URL with a mode mode that is either "No CORS", "Anonymous", or "Use Credentials", optionally using a referrer source referrer source, with an origin origin, and with a default origin behaviour default which is either "taint" or "fail", it must run these steps:

  1. Let req be a new request.

  2. Set req's origin to origin.

  3. Set req's mode to the value corresponding to the first matching statement:

    mode is "No CORS" and default is "fail"
    same-origin
    mode is "No CORS" and default is "taint"
    tainted cross-origin
    Otherwise
    CORS
  4. If mode is "Anonymous", set req's omit credentials mode to always.

  5. Set req's referrer to the result of determining referrer using referrer source (if given).

  6. fetch req.

To determine referrer optionally using a referrer source referrer source, within the context of either fetch or potentially CORS-enabled fetch, run these steps:

  1. If there is a specific referrer source, and it is a URL, return referrer source.

  2. Let document be the appropriate Document as given by the following list:

    If there is a referrer source
    referrer source.
    When navigating
    The active document of the source browsing context.
    When fetching resources for an element
    The element's node document.
  3. While document is an iframe srcdoc document, set document to document's browsing context's browsing context container's Document instead.

  4. If document's origin is not a scheme/host/port tuple, let referrer be null.

  5. Otherwise, let referrer be the document's address of document.

  6. If referrer's scheme is about/data/javascript, set referrer to null.

  7. Return referrer.

References

[COOKIES]
HTTP State Management Mechanism, Adam Barth. IETF.
[CORS]
(Non-normative) CORS (obsolete), Anne van Kesteren. W3C.
[ENCODING]
Encoding, Anne van Kesteren. WHATWG.
[HSTS]
HTTP Strict Transport Security, Jeff Hodges, Collin Jackson and Adam Barth. IETF.
[HTML]
(Non-normative) HTML, Ian Hickson. WHATWG.
[HTTP]
Hypertext Transfer Protocol -- HTTP/1.1, Roy Fielding, James Gettys, Jeffrey Mogul et al.. IETF.
[HTTPAUTH]
HTTP Authentication: Basic and Digest Access Authentication, J. Franks, Phillip Hallam-Baker, J. Hostetler et al.. IETF.
[HTTPVERBSEC]
Multiple vendors' web servers enable HTTP TRACE method by default. US-CERT.
Microsoft Internet Information Server (IIS) vulnerable to cross-site scripting via HTTP TRACK method. US-CERT.
HTTP proxy default configurations allow arbitrary TCP connections. US-CERT.
[ORIGIN]
The Web Origin Concept, Adam Barth. IETF.
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
[URL]
URL, Anne van Kesteren. WHATWG.
[XHR]
(Non-normative) XMLHttpRequest, Anne van Kesteren. WHATWG.

Acknowledgments

The editor would like to thank Adam Barth, Alexey Proskuryakov, Arne Johannessen, Arthur Barstow, Benjamin Hawkes-Lewis, Bert Bos, Björn Höhrmann, Boris Zbarsky, Brad Hill, Brad Porter, Cameron McCormack, Clement Pellerin, Collin Jackson, David Håsäther, David Orchard, Dean Jackson, Eric Lawrence, Frank Ellerman, Frederick Hirsch, Gavin Carothers, Glenn Maynard, Graham Klyne, Hal Lockhart, Hallvord R. M. Steen, Henri Sivonen, Ian Hickson, Janusz Majnert, Jesse M. Heines, Jonas Sicking, Julian Reschke, Lachlan Hunt, Lucas Gonze, 呂康豪 (Kang-Hao Lu), Maciej Stachowiak, Marc Silbey, Marcos Caceres, Mark Nottingham, Mark S. Miller, Martin Dürst, Matt Oshry, Matt Womer, Mhano Harkness, Michael Smith, Mohamed Zergaoui, Nikhil Marathe, Nikunj Mehta, Odin Hørthe Omdal, Ondřej Žára, Philip Jägenstedt, R. Auburn, Sharath Udupa, Simon Pieters, Sunava Dutta, Surya Ismail, Takeshi Yoshino, Thomas Roessler, Tyler Close, Vladimir Dzhuvinov, Wayne Carr, and Zhenbin Xu for being awesome.