Fetch

Goals

The goal is to unify fetching across the web platform and provide consistent handling of everything that involves, including:

• URL schemes
• Redirects
• Cross-origin semantics
• CSP [CSP]
• Fetch Metadata [FETCH-METADATA]
• Service workers [SW]
• Mixed Content [MIX]
• Upgrade Insecure Requests [UPGRADE-INSECURE-REQUESTS]
• `Referer` [REFERRER]

To do so it also supersedes the HTTP `Origin` header semantics originally defined in The Web Origin Concept. [ORIGIN]

1. Preface

At a high level, fetching a resource is a fairly simple operation. A request goes in, a response comes out. The details of that operation are however quite involved and used to not be written down carefully and differ from one API to the next.

Numerous APIs provide the ability to fetch a resource, e.g. HTML’s img and script element, CSS' cursor and list-style-image, the navigator.sendBeacon() and self.importScripts() JavaScript APIs. The Fetch Standard provides a unified architecture for these features so they are all consistent when it comes to various aspects of fetching, such as redirects and the CORS protocol.

The Fetch Standard also defines the fetch() JavaScript API, which exposes most of the networking functionality at a fairly low level of abstraction.

2. Infrastructure

This specification depends on the Infra Standard. [INFRA]

This specification uses terminology from the ABNF, Encoding, HTML, HTTP, IDL, MIME Sniffing, Streams, and URL Standards. [ABNF] [ENCODING] [HTML] [HTTP] [WEBIDL] [MIMESNIFF] [STREAMS] [URL]

ABNF means ABNF as augmented by HTTP (in particular the addition of #) and RFC 7405. [RFC7405]

Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication). [COOKIES] [TLS] [HTTP-AUTH]

A fetch params is a struct used as a bookkeeping detail by the fetch algorithm. It has the following items:

request

A request.

process request body chunk length (default null)

process request end-of-body (default null)

process response (default null)

process response end-of-body (default null)

process response done (default null)

Null or an algorithm.

task destination (default null)

Null, a global object, or a parallel queue.

cross-origin isolated capability (default false)

A boolean.

timing info

A fetch timing info.

A fetch timing info is a struct used to maintain timing information needed by Resource Timing and Navigation Timing. It has the following items: [RESOURCE-TIMING] [NAVIGATION-TIMING]

start time (default 0)

redirect start time (default 0)

redirect end time (default 0)

post-redirect start time (default 0)

final service worker start time (default 0)

final network-request start time (default 0)

final network-response start time (default 0)

end time (default 0)

A DOMHighResTimeStamp.

encoded body size (default 0)

decoded body size (default 0)

A number.

final connection timing info (default null)

Null or a connection timing info.

To create an opaque timing info, given a fetch timing info timingInfo, return a new fetch timing info whose start time and post-redirect start time are timingInfo’s start time.

To update timing info from stored response, given a connection timing info timingInfo and a response response, perform the following steps:

1. Let storedTimingInfo be response’s timing info.

2. If storedTimingInfo is null, then return.

3. Set timingInfo’s encoded body size to storedTimingInfo’s encoded body size.

4. Set timingInfo’s decoded body size to storedTimingInfo’s decoded body size.

To queue a fetch task, given an algorithm algorithm, a global object or a parallel queue taskDestination, run these steps:

1. If taskDestination is a parallel queue, then enqueue algorithm to taskDestination.

2. Otherwise, queue a global task on the networking task source with taskDestination and algorithm.

To serialize an integer, represent it as a string of the shortest possible decimal number.

This will be replaced by a more descriptive algorithm in Infra. See infra/201.

2.1. URL

A local scheme is a scheme that is "about", "blob", or "data".

A URL is local if its scheme is a local scheme.

This definition is also used by Referrer Policy. [REFERRER]

An HTTP(S) scheme is a scheme that is "http" or "https".

A fetch scheme is a scheme that is "about", "blob", "data", "file", or an HTTP(S) scheme.

HTTP(S) scheme and fetch scheme are also used by HTML. [HTML]

2.2. 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., data URLs).

An HTTP tab or space is U+0009 TAB or U+0020 SPACE.

HTTP whitespace is U+000A LF, U+000D CR, or an HTTP tab or space.

HTTP whitespace is only useful for specific constructs that are reused outside the context of HTTP headers (e.g., MIME types). For HTTP header values, using HTTP tab or space is preferred, and outside that context ASCII whitespace is preferred. Unlike ASCII whitespace this excludes U+000C FF.

An HTTP newline byte is 0x0A (LF) or 0x0D (CR).

An HTTP tab or space byte is 0x09 (HT) or 0x20 (SP).

An HTTP whitespace byte is an HTTP newline byte or HTTP tab or space byte.

To collect an HTTP quoted string from a string input, given a position variable position and optionally an extract-value flag, run these steps:

1. Let positionStart be position.

2. Let value be the empty string.

3. Assert: the code point at position within input is U+0022 (").

4. Advance position by 1.

5. While true:

   1. Append the result of collecting a sequence of code points that are not U+0022 (") or U+005C (\) from input, given position, to value.

   2. If position is past the end of input, then break.

   3. Let quoteOrBackslash be the code point at position within input.

   4. Advance position by 1.

   5. If quoteOrBackslash is U+005C (\), then:

      1. If position is past the end of input, then append U+005C (\) to value and break.

      2. Append the code point at position within input to value.

      3. Advance position by 1.

   6. Otherwise:

      1. Assert: quoteOrBackslash is U+0022 (").

      2. Break.

6. If the extract-value flag is set, then return value.

7. Return the code points from positionStart to position, inclusive, within input.

2.2.1. Methods

A method is a byte sequence that matches the method token production.

A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`.

A forbidden method is a method that is a byte-case-insensitive match for `CONNECT`, `TRACE`, or `TRACK`. [HTTPVERBSEC1], [HTTPVERBSEC2], [HTTPVERBSEC3]

To normalize a method, if it is a byte-case-insensitive match for `DELETE`, `GET`, `HEAD`, `OPTIONS`, `POST`, or `PUT`, byte-uppercase it.

Normalization is done for backwards compatibility and consistency across APIs as methods are actually "case-sensitive".

Using `patch` is highly likely to result in a `405 Method Not Allowed`. `PATCH` is much more likely to succeed.

There are no restrictions on methods. `CHICKEN` is perfectly acceptable (and not a misspelling of `CHECKIN`). Other than those that are normalized there are no casing restrictions either. `Egg` or `eGg` would be fine, though uppercase is encouraged for consistency.

2.2.2. Headers

A header list is a list of zero or more headers. It is initially the empty list.

A header list is essentially a specialized multimap: an ordered list of key-value pairs with potentially duplicate keys.

To get a structured field value given a header name name and a string type from a header list list, run these steps:

1. Assert: type is one of "dictionary", "list", or "item".

2. Let value be the result of getting name from list.

3. If value is null, then return null.

4. Let result be the result of parsing structured fields with input_string set to value and header_type set to type.

5. If parsing failed, then return null.

6. Return result.

Get a structured field value intentionally does not distinguish between a header not being present and its value failing to parse as a structured field value. This ensures uniform processing across the web platform.

To set a structured field value given a tuple (header name name, structured field value structuredValue), in a header list list, run these steps:

1. Let serializedValue be the result of executing the serializing structured fields algorithm on structuredValue.

2. Set (name, serializedValue) in list.

Structured field values are defined as objects which HTTP can (eventually) serialize in interesting and efficient ways. For the moment, Fetch only supports header values as byte sequences, which means that these objects can be set in header lists only via serialization, and they can be obtained from header lists only by parsing. In the future the fact that they are objects might be preserved end-to-end. [RFC8941]

A header list list contains a header name name if list contains a header whose name is a byte-case-insensitive match for name.

To get a header name name from a header list list, run these steps:

1. If list does not contain name, then return null.

2. Return the values of all headers in list whose name is a byte-case-insensitive match for name, separated from each other by 0x2C 0x20, in order.

To get, decode, and split a header name name from header list list, run these steps:

1. Let initialValue be the result of getting name from list.

2. If initialValue is null, then return null.

3. Let input be the result of isomorphic decoding initialValue.

4. Let position be a position variable for input, initially pointing at the start of input.

5. Let values be a list of strings, initially empty.

6. Let value be the empty string.

7. While position is not past the end of input:

   1. Append the result of collecting a sequence of code points that are not U+0022 (") or U+002C (,) from input, given position, to value.

      The result might be the empty string.

   2. If position is not past the end of input, then:

      1. If the code point at position within input is U+0022 ("), then:

         1. Append the result of collecting an HTTP quoted string from input, given position, to value.

         2. If position is not past the end of input, then continue.

      2. Otherwise:

         1. Assert: the code point at position within input is U+002C (,).

         2. Advance position by 1.

   3. Remove all HTTP tab or space from the start and end of value.

   4. Append value to values.

   5. Set value to the empty string.

8. Return values.

A: nosniff,

A: nosniff
B: sniff
A:

A: text/html;", x/x

A: text/html;"
A: x/x

A: x/x;test="hi",y/y

A: x/x;test="hi"
C: **bingo**
A: y/y

A: x / x,,,1

A: x / x
A: ,
A: 1

A: "1,2", 3

A: "1,2"
D: 4
A: 3

To append a header (name, value) to a header list list, run these steps:

1. If list contains name, then set name to the first such header’s name.

   This reuses the casing of the name of the header already in list, if any. If there are multiple matched headers their names will all be identical.

2. Append (name, value) to list.

To delete a header name name from a header list list, remove all headers whose name is a byte-case-insensitive match for name from list.

To set a header (name, value) in a header list list, run these steps:

1. If list contains name, then set the value of the first such header to value and remove the others.

2. Otherwise, append header (name, value) to list.

To combine a header (name, value) in a header list list, run these steps:

1. If list contains name, then set the value of the first such header to its value, followed by 0x2C 0x20, followed by value.

2. Otherwise, append (name, value) to list.

Combine is used by XMLHttpRequest and the WebSocket protocol handshake.

To convert header names to a sorted-lowercase set, given a list of names headerNames, run these steps:

1. Let headerNamesSet be a new ordered set.

2. For each name of headerNames, append the result of byte-lowercasing name to headerNamesSet.

3. Return the result of sorting headerNamesSet in ascending order with byte less than.

To sort and combine a header list list, run these steps:

1. Let headers be an empty list of headers with the key being the name and value the value.

2. Let names be the result of convert header names to a sorted-lowercase set with all the names of the headers in list.

3. For each name in names:

   1. Let value be the result of getting name from list.

   2. Assert: value is not null.

   3. Append (name, value) to headers.

4. Return headers.

A header is a tuple that consists of a name (a header name) and value (a header value).

A header name is a byte sequence that matches the field-name token production.

A header value is a byte sequence that matches the following conditions:

• Has no leading or trailing HTTP tab or space bytes.

• Contains no 0x00 (NUL) or HTTP newline bytes.

The definition of header value is not defined in terms of an HTTP token production as it is broken.

To normalize a byte sequence potentialValue, remove any leading and trailing HTTP whitespace bytes from potentialValue.

To determine whether a header (name, value) is a CORS-safelisted request-header, run these steps:

1. If value’s length is greater than 128, then return false.

2. Byte-lowercase name and switch on the result:

   `accept`

   If value contains a CORS-unsafe request-header byte, then return false.

   `accept-language`

   `content-language`

   If value contains a byte that is not in the range 0x30 (0) to 0x39 (9), inclusive, is not in the range 0x41 (A) to 0x5A (Z), inclusive, is not in the range 0x61 (a) to 0x7A (z), inclusive, and is not 0x20 (SP), 0x2A (*), 0x2C (,), 0x2D (-), 0x2E (.), 0x3B (;), or 0x3D (=), then return false.

   `content-type`

   1. If value contains a CORS-unsafe request-header byte, then return false.

   2. Let mimeType be the result of parsing value.

   3. If mimeType is failure, then return false.

   4. If mimeType’s essence is not "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", then return false.

   This intentionally does not use extract a MIME type as that algorithm is rather forgiving and servers are not expected to implement it.

   If extract a MIME type were used the following request would not result in a CORS preflight and a naïve parser on the server might treat the request body as JSON:

   fetch("https://victim.example/naïve-endpoint", {
     method: "POST",
     headers: [
       ["Content-Type", "application/json"],
       ["Content-Type", "text/plain"]
     ],
     credentials: "include",
     body: JSON.stringify(exerciseForTheReader)
   });
   

   `range`

   If value is not a simple range header value, then return false.

   Otherwise

   Return false.

3. Return true.

There are limited exceptions to the `Content-Type` header safelist, as documented in CORS protocol exceptions.

A CORS-unsafe request-header byte is a byte byte for which one of the following is true:

• byte is less than 0x20 and is not 0x09 HT

• byte is 0x22 ("), 0x28 (left parenthesis), 0x29 (right parenthesis), 0x3A (:), 0x3C (<), 0x3E (>), 0x3F (?), 0x40 (@), 0x5B ([), 0x5C (\), 0x5D (]), 0x7B ({), 0x7D (}), or 0x7F DEL.

The CORS-unsafe request-header names, given a header list headers, are determined as follows:

1. Let unsafeNames be a new list.

2. Let potentiallyUnsafeNames be a new list.

3. Let safelistValueSize be 0.

4. For each header of headers:

   1. If header is not a CORS-safelisted request-header, then append header’s name to unsafeNames.

   2. Otherwise, append header’s name to potentiallyUnsafeNames and increase safelistValueSize by header’s value’s length.

5. If safelistValueSize is greater than 1024, then for each name of potentiallyUnsafeNames, append name to unsafeNames.

6. Return the result of convert header names to a sorted-lowercase set with unsafeNames.

A CORS non-wildcard request-header name is a header name that is a byte-case-insensitive match for `Authorization`.

A privileged no-CORS request-header name is a header name that is a byte-case-insensitive match for one of

• `Range`.

A CORS-safelisted response-header name, given a list of header names list, is a header name that is a byte-case-insensitive match for one of

• `Cache-Control`
• `Content-Language`
• `Content-Length`
• `Content-Type`
• `Expires`
• `Last-Modified`
• `Pragma`
• Any item in list that is not a forbidden response-header name.

A no-CORS-safelisted request-header name is a header name that is a byte-case-insensitive match for one of

• `Accept`
• `Accept-Language`
• `Content-Language`
• `Content-Type`

To determine whether a header header is a no-CORS-safelisted request-header, run these steps:

1. If header’s name is not a no-CORS-safelisted request-header name, then return false.

2. Return whether header is a CORS-safelisted request-header.

A forbidden header name is a header name that is a byte-case-insensitive match for one of

• `Accept-Charset`
• `Accept-Encoding`
• `Access-Control-Request-Headers`
• `Access-Control-Request-Method`
• `Connection`
• `Content-Length`
• `Cookie`
• `Cookie2`
• `Date`
• `DNT`
• `Expect`
• `Host`
• `Keep-Alive`
• `Origin`
• `Referer`
• `TE`
• `Trailer`
• `Transfer-Encoding`
• `Upgrade`
• `Via`

or a header name that when byte-lowercased starts with `proxy-` or `sec-`.

These are forbidden so the user agent remains in full control over them. Header names starting with `Sec-` are reserved to allow new headers to be minted that are safe from APIs using fetch that allow control over headers by developers, such as XMLHttpRequest. [XHR]

A forbidden response-header name is a header name that is a byte-case-insensitive match for one of:

• `Set-Cookie`
• `Set-Cookie2`

A request-body-header name is a header name that is a byte-case-insensitive match for one of:

• `Content-Encoding`
• `Content-Language`
• `Content-Location`
• `Content-Type`

To extract header values given a header header, run these steps:

1. If parsing header’s value, per the ABNF for header’s name, fails, then return failure.

2. Return one or more values resulting from parsing header’s value, per the ABNF for header’s name.

To extract header list values given a header name name and a header list list, run these steps:

1. If list does not contain name, then return null.

2. If the ABNF for name allows a single header and list contains more than one, then return failure.

   If different error handling is needed, extract the desired header first.

3. Let values be an empty list.

4. For each header header list contains whose name is name:

   1. Let extract be the result of extracting header values from header.

   2. If extract is failure, then return failure.

   3. Append each value in extract, in order, to values.

5. Return values.

To determine if a byte sequence value is a simple range header value, perform the following steps. They return a boolean.

1. Let data be the isomorphic decoding of value.

2. If data does not start with "bytes=", then return false.

3. Let position be a position variable for data, initially pointing at the 6th code point of data.

4. Let rangeStart be the result of collecting a sequence of code points that are ASCII digits, from data given position.

5. If the code point at position within data is not U+002D (-), then return false.

6. Advance position by 1.

7. Let rangeEnd be the result of collecting a sequence of code points that are ASCII digits, from data given position.

8. If position is not past the end of data, then return false.

9. If rangeEnd’s length is 0, then return true.

   The range end can be omitted, e.g., `bytes=0-` is valid.

10. If rangeStart, interpreted as decimal number, is greater than rangeEnd, interpreted as decimal number, then return false.

11. Return true.

A simple range header value is a subset of allowed range header values, but it is the most common form used by user agents when requesting media or resuming downloads. This format of range header value can be set using add a range header.

A default `User-Agent` value is an implementation-defined header value for the `User-Agent` header.

2.2.3. Statuses

A status is an integer in the range 0 to 999, inclusive.

Various edge cases in mapping HTTP/1’s status-code to this concept are worked on in issue #1156.

A null body status is a status that is 101, 204, 205, or 304.

An ok status is a status in the range 200 to 299, inclusive.

A redirect status is a status that is 301, 302, 303, 307, or 308.

2.2.4. Bodies

A body consists of:

• A stream (a ReadableStream object).

• A source (null, a byte sequence, a Blob object, or a FormData object), initially null.

• A length (null or an integer), initially null.

To clone a body body, run these steps:

1. Let « out1, out2 » be the result of teeing body’s stream.

2. Set body’s stream to out1.

3. Return a body whose stream is out2 and other members are copied from body.

To incrementally read a body body, given an algorithm processBodyChunk, an algorithm processEndOfBody, an algorithm processBodyError, and an optional null, parallel queue, or global object taskDestination (default null), run these steps. processBodyChunk must be an algorithm accepting a byte sequence. processEndOfBody must be an algorithm accepting no arguments. processBodyError must be an algorithm accepting an exception.

1. If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.

2. Let reader be the result of getting a reader for body’s stream.

   This operation will not throw an exception.

3. Perform the incrementally-read loop given reader, taskDestination, processBodyChunk, processEndOfBody, and processBodyError.

To perform the incrementally-read loop, given a ReadableStreamDefaultReader object reader, parallel queue or global object taskDestination, algorithm processBodyChunk, algorithm processEndOfBody, and algorithm processBodyError:

1. Let readRequest be the following read request:

   chunk steps, given chunk

   1. Let continueAlgorithm be null.

   2. If chunk is not a Uint8Array object, then set continueAlgorithm to this step: run processBodyError given a TypeError.

   3. Otherwise:

      1. Let bytes be a copy of chunk.

         Implementations are strongly encouraged to use an implementation strategy that avoids this copy where possible.

      2. Set continueAlgorithm to these steps:

         1. Run processBodyChunk given bytes.

         2. Perform the incrementally-read loop given reader, taskDestination, processBodyChunk, processEndOfBody, and processBodyError.

   4. Queue a fetch task given continueAlgorithm and taskDestination.

   close steps

   1. Queue a fetch task given processEndOfBody and taskDestination.

   error steps, given e

   1. Queue a fetch task to run processBodyError given e, with taskDestination.

2. Read a chunk from reader given readRequest.

To fully read a body body, given an algorithm processBody, an algorithm processBodyError, and an optional null, parallel queue, or global object taskDestination (default null), run these steps. processBody must be an algorithm accepting a byte sequence. processBodyError must be an algorithm accepting no arguments.

1. If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.

2. Let promise be the result of fully reading body as promise given body.

3. Let fulfilledSteps given a byte sequence bytes be to queue a fetch task to run processBody given bytes, with taskDestination.

4. Let rejectedSteps be to queue a fetch task to run processBodyError, with taskDestination.

5. React to promise with fulfilledSteps and rejectedSteps.

To fully read body as promise, given a body body, run these steps:

1. Let reader be the result of getting a reader for body’s stream. If that threw an exception, then return a promise rejected with that exception.

2. Return the result of reading all bytes from reader.

To handle content codings given codings and bytes, run these steps:

1. If codings are not supported, then return bytes.

2. Return the result of decoding bytes with codings as explained in HTTP, if decoding does not result in an error, and failure otherwise. [HTTP] [HTTP-SEMANTICS]

2.2.5. Requests

The input to fetch is a request.

A request has an associated method (a method). Unless stated otherwise it is `GET`.

This can be updated during redirects to `GET` as described in HTTP fetch.

A request has an associated URL (a URL).

Implementations are encouraged to make this a pointer to the first URL in request’s URL list. It is provided as a distinct field solely for the convenience of other standards hooking into Fetch.

A request has an associated local-URLs-only flag. Unless stated otherwise it is unset.

A request has an associated header list (a header list). Unless stated otherwise it is empty.

A request has an associated unsafe-request flag. Unless stated otherwise it is unset.

The unsafe-request flag is set by APIs such as fetch() and XMLHttpRequest to ensure a CORS-preflight fetch is done based on the supplied method and header list. It does not free an API from outlawing forbidden methods and forbidden header names.

A request has an associated body (null, a byte sequence, or a body). Unless stated otherwise it is null.

A byte sequence will be safely extracted into a body early on in fetch. As part of HTTP fetch it is possible for this field to be set to null due to certain redirects.

A request has an associated client (null or an environment settings object).

A request has an associated reserved client (null, an environment, or an environment settings object). Unless stated otherwise it is null.

This is only used by navigation requests and worker requests, but not service worker requests. It references an environment for a navigation request and an environment settings object for a worker request.

A request has an associated replaces client id (a string). Unless stated otherwise it is the empty string.

This is only used by navigation requests. It is the id of the target browsing context’s active document’s environment settings object.

A request has an associated window ("no-window", "client", or an environment settings object whose global object is a Window object). Unless stated otherwise it is "client".

The "client" value is changed to "no-window" or request’s client during fetching. It provides a convenient way for standards to not have to explicitly set request’s window.

A request has an associated boolean keepalive. Unless stated otherwise it is false.

This can be used to allow the request to outlive the environment settings object, e.g., navigator.sendBeacon and the HTML img element set this flag. Requests with this flag set are subject to additional processing requirements.

A request has an associated service-workers mode, that is "all" or "none". Unless stated otherwise it is "all".

A request has an associated initiator, which is the empty string, "download", "imageset", "manifest", "prefetch", "prerender", or "xslt". Unless stated otherwise it is the empty string.

A request’s initiator is not particularly granular for the time being as other specifications do not require it to be. It is primarily a specification device to assist defining CSP and Mixed Content. It is not exposed to JavaScript. [CSP] [MIX]

A request has an associated destination, which is the empty string, "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "manifest", "object", "paintworklet", "report", "script", "serviceworker", "sharedworker", "style", "track", "video", "worker", or "xslt". Unless stated otherwise it is the empty string.

A request’s destination is script-like if it is "audioworklet", "paintworklet", "script", "serviceworker", "sharedworker", or "worker".

Algorithms that use script-like should also consider "xslt" as that too can cause script execution. It is not included in the list as it is not always relevant and might require different behavior.

A request has an associated priority (null or a user-agent-defined object). Unless otherwise stated it is null.

A request has an associated origin, which is "client" or an origin. Unless stated otherwise it is "client".

"client" is changed to an origin during fetching. It provides a convenient way for standards to not have to set request’s origin.

A request has an associated policy container, which is "client" or a policy container. Unless stated otherwise it is "client".

"client" is changed to a policy container during fetching. It provides a convenient way for standards to not have to set request’s policy container.

A request has an associated referrer, which is "no-referrer", "client", or a URL. Unless stated otherwise it is "client".

"client" is changed to "no-referrer" or a URL during fetching. It provides a convenient way for standards to not have to set request’s referrer.

A request has an associated referrer policy, which is a referrer policy. Unless stated otherwise it is the empty string. [REFERRER]

This can be used to override the referrer policy to be used for this request.

A request has an associated mode, which is "same-origin", "cors", "no-cors", "navigate", or "websocket". Unless stated otherwise, it is "no-cors".

A request has an associated use-CORS-preflight flag. Unless stated otherwise, it is unset.

The use-CORS-preflight flag being set is one of several conditions that results in a CORS-preflight request. The use-CORS-preflight flag is set if either one or more event listeners are registered on an XMLHttpRequestUpload object or if a ReadableStream object is used in a request.

A request has an associated credentials mode, which is "omit", "same-origin", or "include". Unless stated otherwise, it is "same-origin".

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

A request has an associated cache mode, which is "default", "no-store", "reload", "no-cache", "force-cache", or "only-if-cached". Unless stated otherwise, it is "default".

A request has an associated redirect mode, which is "follow", "error", or "manual". Unless stated otherwise, it is "follow".

A request has associated integrity metadata (a string). Unless stated otherwise, it is the empty string.

A request has associated cryptographic nonce metadata (a string). Unless stated otherwise, it is the empty string.

A request has associated parser metadata which is the empty string, "parser-inserted", or "not-parser-inserted". Unless otherwise stated, it is the empty string.

A request’s cryptographic nonce metadata and parser metadata are generally populated from attributes and flags on the HTML element responsible for creating a request. They are used by various algorithms in Content Security Policy to determine whether requests or responses are to be blocked in a given context. [CSP]

A request has an associated reload-navigation flag. Unless stated otherwise, it is unset.

This flag is for exclusive use by HTML’s navigate algorithm. [HTML]

A request has an associated history-navigation flag. Unless stated otherwise, it is unset.

This flag is for exclusive use by HTML’s navigate algorithm. [HTML]

A request has an associated boolean user-activation. Unless stated otherwise, it is false.

This is for exclusive use by HTML’s navigate algorithm. [HTML]

A request has an associated tainted origin flag. Unless stated otherwise, it is unset.

A request has an associated URL list (a list of one or more URLs). Unless stated otherwise, it is a list containing a copy of request’s URL.

A request has an associated current URL. It is a pointer to the last URL in request’s URL list.

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

A request has an associated response tainting, which is "basic", "cors", or "opaque". Unless stated otherwise, it is "basic".

A request has an associated prevent no-cache cache-control header modification flag. Unless stated otherwise, it is unset.

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

A request has an associated timing allow failed flag. Unless stated otherwise, it is unset.

A request’s tainted origin flag, URL list, current URL, redirect count, response tainting, done flag, and timing allow failed flag are used as bookkeeping details by the fetch algorithm.

A subresource request is a request whose destination is "audio", "audioworklet", "font", "image", "manifest", "paintworklet", "script", "style", "track", "video", "xslt", or the empty string.

A non-subresource request is a request whose destination is "document", "embed", "frame", "iframe", "object", "report", "serviceworker", "sharedworker", or "worker".

A navigation request is a request whose destination is "document", "embed", "frame", "iframe", or "object".

See handle fetch for usage of these terms. [SW]

Serializing a request origin, given a request request, is to run these steps:

1. If request’s tainted origin flag is set, then return "null".

2. Return request’s origin, serialized.

Byte-serializing a request origin, given a request request, is to return the result of serializing a request origin with request, isomorphic encoded.

To clone a request request, run these steps:

1. Let newRequest be a copy of request, except for its body.

2. If request’s body is non-null, set newRequest’s body to the result of cloning request’s body.

3. Return newRequest.

To add a range header to a request request, with an integer first, and an optional integer last, run these steps:

1. Assert: last is not given, or first is less than or equal to last.

2. Let rangeValue be `bytes=`.

3. Serialize and isomorphic encode first, and append the result to rangeValue.

4. Append 0x2D (-) to rangeValue.

5. If last is given, then serialize and isomorphic encode it, and append the result to rangeValue.

6. Append (`Range`, rangeValue) to request’s header list.

A range header denotes an inclusive byte range. There a range header where first is 0 and last is 500, is a range of 501 bytes.

Features that combine multiple responses into one logical resource are historically a source of security bugs. Please seek security review for features that deal with partial responses.

To serialize a response URL for reporting, given a response response, run these steps:

1. Assert: response’s URL list is not empty.

2. Let url be a copy of response’s URL list’s first element.

   This is not response’s URL in order to avoid leaking information about redirect targets (see similar considerations for CSP reporting too). [CSP]

3. Set the username given url and the empty string.

4. Set the password given url and the empty string.

5. Return the serialization of url with exclude fragment set to true.

2.2.6. 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 "basic", "cors", "default", "error", "opaque", or "opaqueredirect". Unless stated otherwise, it is "default".

A response can have an associated aborted flag, which is initially unset.

This indicates that the request was intentionally aborted by the developer or end-user.

A response has an associated URL. It is a pointer to the last URL in response’s URL list and null if response’s URL list is empty.

A response has an associated URL list (a list of zero or more URLs). Unless stated otherwise, it is the empty list.

Except for the last URL, if any, a response’s URL list is not exposed to script as that would violate atomic HTTP redirect handling.

A response has an associated status, which is a status. Unless stated otherwise it is 200.

A response has an associated status message. Unless stated otherwise it is the empty byte sequence.

Responses over an HTTP/2 connection will always have the empty byte sequence as status message as HTTP/2 does not support them.

A response has an associated header list (a header list). Unless stated otherwise it is empty.

A response has an associated body (null or a body). Unless stated otherwise it is null.

The source and length concepts of a network’s response’s body are always null.

A response has an associated cache state (the empty string, "local", or "validated"). Unlesss stated otherwise, it is the empty string.

This is intended for usage by Service Workers and Resource Timing. [SW] [RESOURCE-TIMING]

A response has an associated CORS-exposed header-name list (a list of zero or more header names). The list is empty unless otherwise specified.

A response will typically get its CORS-exposed header-name list set by extracting header values from the `Access-Control-Expose-Headers` header. This list is used by a CORS filtered response to determine which headers to expose.

A response has an associated range-requested flag, which is initially unset.

This is used to ensure to prevent a partial response from an earlier ranged request being provided to an API that didn’t make a range request. See the flag’s usage for a detailed description of the attack.

A response has an associated timing allow passed flag, which is initially unset.

This is used so that the caller to a fetch can determine if sensitive timing data is allowed on the resource fetched by looking at the flag of the response returned. Because the flag on the response of a redirect has to be set if it was set for previous responses in the redirect chain, this is also tracked internally using the request’s timing allow failed flag.

A response has an associated timing info (null or a fetch timing info), which is initially null.

A response has an associated service worker timing info (null or a service worker timing info), which is initially null.

A response whose type is "error" and aborted flag is set is known as an aborted network error.

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

A network error is a response whose status is always 0, status message is always the empty byte sequence, header list is always empty, and body is always null.

A filtered response is a limited view on a response that is not a network error. 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 needs to be exposed for legacy reasons, e.g., to feed image data to a decoder, the associated internal response can be used, which is only "accessible" to internal specification algorithms and is never a filtered response itself.

A basic filtered response is a filtered response whose type is "basic" and header list excludes any headers in internal response’s header list whose name is a forbidden response-header name.

A CORS filtered response is a filtered response whose type is "cors" and header list excludes any headers in internal response’s header list whose name is not a CORS-safelisted response-header name, given internal response’s CORS-exposed header-name list.

An opaque filtered response is a filtered response whose type is "opaque", URL list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, and body is null.

An opaque-redirect filtered response is a filtered response whose type is "opaqueredirect", status is 0, status message is the empty byte sequence, header list is empty, and body is null.

To clone a response response, run these steps:

1. If response is a filtered response, then return a new identical filtered response whose internal response is a clone of response’s internal response.

2. Let newResponse be a copy of response, except for its body.

3. If response’s body is non-null, then set newResponse’s body to the result of cloning response’s body.

4. Return newResponse.

A fresh response is a response whose current age is within its freshness lifetime.

A stale-while-revalidate response is a response that is not a fresh response and whose current age is within the stale-while-revalidate lifetime.

A stale response is a response that is not a fresh response or a stale-while-revalidate response.

The location URL of a response response, given null or an ASCII string requestFragment, is the value returned by the following steps. They return null, failure, or a URL.

1. If response’s status is not a redirect status, then return null.

2. Let location be the result of extracting header list values given `Location` and response’s header list.

3. If location is a header value, then set location to the result of parsing location with response’s URL.

   If response was constructed through the Response constructor, response’s URL will be null, meaning that location will only parse successfully if it is an absolute-URL-with-fragment string.

4. If location is a URL whose fragment is null, then set location’s fragment to requestFragment.

   This ensures that synthetic (indeed, all) responses follow the processing model for redirects defined by HTTP. [HTTP-SEMANTICS]

5. Return location.

The location URL algorithm is exclusively used for redirect handling in this standard and in HTML’s navigate algorithm which handles redirects manually. [HTML]

2.2.7. Miscellaneous

A potential destination is "fetch" or a destination which is not the empty string.

To translate a potential destination potentialDestination, run these steps:

1. If potentialDestination is "fetch", then return the empty string.

2. Assert: potentialDestination is a destination.

3. Return potentialDestination.

2.3. Authentication entries

An authentication entry and a proxy-authentication entry are tuples of username, password, and realm, used for HTTP authentication and HTTP proxy authentication, and associated with one or more requests.

User agents should allow both to be cleared together with HTTP cookies and similar tracking functionality.

Further details are defined by HTTP. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]

2.4. Fetch groups

Each environment settings object has an associated fetch group.

A fetch group holds an ordered list of fetch records.

A fetch record has an associated request (a request).

A fetch record has an associated fetch (a fetch algorithm or null).

When a fetch group is terminated, for each associated fetch record whose request’s done flag is unset or keepalive is false, terminate the fetch record’s fetch.

2.5. Resolving domains

To resolve a domain, given a network partition key key and a domain domain:

1. If domain is a host whose public suffix is "localhost", then return « ::1, 127.0.0.1 ».

2. Perform an implementation-defined operation to turn domain into a set of one or more IP addresses. If this operation succeeds, return the set of IP addresses.

3. Return failure.

The results of resolve a domain may be cached. If they are cached, key should be used as part of the cache key.

To resolve an origin, given a network partition key key and an origin origin:

1. If origin’s host is an IP address, then return « origin’s host ».

2. Return the result of running resolve a domain given key and origin’s host.

The same caveat applies. Do not build on this without having a considered discussion with the Fetch Standard community first.

2.6. Connections

A user agent has an associated connection pool. A connection pool is an ordered set of zero or more connections. Each connection is identified by an associated key (a network partition key), origin (an origin), and credentials (a boolean).

Each connection has an associated timing info (a connection timing info).

A connection timing info is a struct used to maintain timing information pertaining to the process of obtaining a connection. It has the following items:

domain lookup start time (default 0)

domain lookup end time (default 0)

connection start time (default 0)

connection end time (default 0)

secure connection start time (default 0)

A DOMHighResTimeStamp.

ALPN negotiated protocol (default the empty byte sequence)

A byte sequence.

To clamp and coarsen connection timing info, given a connection timing info timingInfo, a DOMHighResTimeStamp defaultStartTime, and a boolean crossOriginIsolatedCapability, run these steps:

1. If timingInfo’s connection start time is less than defaultStartTime, then return a new connection timing info whose domain lookup start time is defaultStartTime, domain lookup end time is defaultStartTime, connection start time is defaultStartTime, connection end time is defaultStartTime, secure connection start time is defaultStartTime, and ALPN negotiated protocol is timingInfo’s ALPN negotiated protocol.

2. Return a new connection timing info whose domain lookup start time is the result of coarsen time given timingInfo’s domain lookup start time and crossOriginIsolatedCapability, domain lookup end time is the result of coarsen time given timingInfo’s domain lookup end time and crossOriginIsolatedCapability, connection start time is the result of coarsen time given timingInfo’s connection start time and crossOriginIsolatedCapability, connection end time is the result of coarsen time given timingInfo’s connection end time and crossOriginIsolatedCapability, secure connection start time is the result of coarsen time given timingInfo’s connection end time and crossOriginIsolatedCapability, and ALPN negotiated protocol is timingInfo’s ALPN negotiated protocol.

A new connection setting is "no", "yes", or "yes-and-dedicated".

To obtain a connection, given a network partition key key, URL url, boolean credentials, an optional new connection setting new (default "no"), and an optional boolean http3Only (default false), run these steps:

1. If new is "no", then:

   1. Let connections be a set of connections in the user agent’s connection pool whose key is key, origin is url’s origin, and credentials is credentials.

   2. If connections is not empty and http3Only is false, then return one of connections.

   3. If there is an HTTP/3 connection in connections, then return that connection.

2. Let proxies be the result of finding proxies for url in an implementation-defined manner. If there are no proxies, let proxies be « "DIRECT" ».

   This is where non-standard technology such as Web Proxy Auto-Discovery Protocol (WPAD) and proxy auto-config (PAC) come into play. The "DIRECT" value means to not use a proxy for this particular url.

3. Let timingInfo be a new connection timing info.

4. For each proxy of proxies:

   1. Set timingInfo’s domain lookup start time to the unsafe shared current time.

   2. Let hosts be « origin’s host ».

   3. If proxy is "DIRECT", then set hosts to the result of running resolve an origin given key and url’s origin.

   4. If hosts is failure, then continue.

   5. Set timingInfo’s domain lookup end time to the unsafe shared current time.

   6. Let connection be the result of running this step: run create a connection given key, url’s origin, credentials, proxy, an implementation-defined host from hosts, timingInfo, and http3Only an implementation-defined number of times, in parallel from each other, and wait for at least 1 to return a value. In an implementation-defined manner, select a value to return from the returned values and return it. Any other returned values that are connections may be closed.

      Essentially this allows an implementation to pick one or more IP addresses from the return value of resolve a domain (assuming proxy is "DIRECT") and race them against each other, favor IPv6 addresses, retry in case of a timeout, etc.

   7. If connection is failure, then continue.

   8. If new is not "yes-and-dedicated", then append connection to the user agent’s connection pool.

   9. Return connection.

5. Return failure.

This is intentionally a little vague as there are a lot of nuances to connection management that are best left to the discretion of implementers. Describing this helps explain the <link rel=preconnect> feature and clearly stipulates that connections are keyed on credentials. The latter clarifies that, e.g., TLS session identifiers are not reused across connections whose credentials are false with connections whose credentials are true.

To create a connection, given a network partition key key, origin origin, boolean credentials, string proxy, host host, connection timing info timingInfo, and boolean http3Only, run these steps:

1. Set timingInfo’s connection start time to the unsafe shared current time.

2. Let connection be a new connection whose key is key, origin is origin, credentials is credentials, and timing info is timingInfo. Record connection timing info given connection and use connection to establish an HTTP connection to host, taking proxy and origin into account. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH] [TLS]

   If http3Only is true, then establish an HTTP/3 connection. [HTTP3]

   When establishing an HTTP/3 connection, include SETTINGS_ENABLE_WEBTRANSPORT with a value of 1 and H3_DATAGRAM with a value of 1 in the initial SETTINGS frame. [WEBTRANSPORT-HTTP3] [HTTP3-DATAGRAM]

   If credentials is false, then do not send a TLS client certificate.

   If establishing a connection does not succeed (e.g., a TCP or TLS error), then return failure.

3. Set timingInfo’s ALPN negotiated protocol to connection’s ALPN Protocol ID, with the following caveats: [RFC7301]

   • When a proxy is configured, if a tunnel connection is established then this must be the ALPN Protocol ID of the tunneled protocol, otherwise it must be the ALPN Protocol ID of the first hop to the proxy.

   • In case the user agent is using an experimental, non-registered protocol, the user agent must use the used ALPN Protocol ID, if any. If ALPN was not used for protocol negotiations, the user agent may use another descriptive string.

     timingInfo’s ALPN negotiated protocol is intended to identify the network protocol in use regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, this is the ALPN Protocol IDs that indicates the protocol in use.

   IANA maintains a list of ALPN Protocol IDs.

4. Return connection.

To record connection timing info given a connection connection, let timingInfo be connection’s timing info and observe these requirements:

• timingInfo’s connection end time should be the unsafe shared current time immediately after establishing the connection to the server or proxy, as follows:

  • The returned time must include the time interval to establish the transport connection, as well as other time intervals such as SOCKS authentication. It must include the time interval to complete enough of the TLS handshake to request the resource.

  • If the user agent used TLS False Start for this connection, this interval must not include the time needed to receive the server’s Finished message. [RFC7918]

  • If the user agent sends the request with early data without waiting for the full handshare to complete, this interval must not include the time needed to receive the server’s ServerHello message. [RFC8470]

  • If the user agent waits for full handshake completion to send the request, this interval includes the full TLS handshake even if other requests were sent using early data on connection.

  Suppose the user agent establishes an HTTP/2 connection over TLS 1.3 to send a GET request and a POST request. It sends the ClientHello at time t1 and then sends the GET request with early data. The POST request is not safe ([HTTP-SEMANTICS], section 4.2.1), so the user agent waits to complete the handshake at time t2 before sending it. Although both requests used the same connection, the GET request reports a connection end time of t1, while the POST request reports t2.

• If a secure transport is used, timingInfo’s secure connection start time should be the result of calling unsafe shared current time immmediately before starting the handshake process to secure connection. [TLS]

The clamp and coarsen connection timing info algorithm ensures that details of reused connections are not exposed and time values are coarsened.

2.7. Network partition keys

A network partition key is a tuple consisting of a site and null or an implementation-defined value.

To determine the network partition key, given an environment settings object settings, run these steps:

1. Let topLevelOrigin be settings’s top-level origin.

2. If topLevelOrigin is null, then set topLevelOrigin to settings’s top-level creation URL’s origin.

3. Assert: topLevelOrigin is an origin.

4. Let topLevelSite be the result of obtaining a site, given topLevelOrigin.

5. Let secondKey be null or an implementation-defined value.

   The second key is intentionally a little vague as the finer points are still evolving. See issue #1035.

6. Return (topLevelSite, secondKey).

To determine the network partition key, given request, run these steps:

1. If request’s reserved client is non-null, then return the result of determining the network partition key given request’s reserved client.

2. If request’s client is non-null, then return the result of determining the network partition key given request’s client.

3. Return null.

2.8. HTTP cache partitions

To determine the HTTP cache partition, given request, run these steps:

1. Let key be the result of determining the network partition key given request.

2. If key is null, then return null.

3. Return the unique HTTP cache associated with key. [HTTP-CACHING]

2.9. Port blocking

New protocols can avoid the need for blocking ports by negotiating the protocol through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in that case. [RFC7301]

To determine whether fetching a request request should be blocked due to a bad port, run these steps:

1. Let url be request’s current URL.

2. If url’s scheme is an HTTP(S) scheme and url’s port is a bad port, then return blocked.

3. Return allowed.

A port is a bad port if it is listed in the first column of the following table.

2.10. Should response to request be blocked due to its MIME type?

Run these steps:

1. Let mimeType be the result of extracting a MIME type from response’s header list.

2. If mimeType is failure, then return allowed.

3. Let destination be request’s destination.

4. If destination is script-like and one of the following is true, then return blocked:

   • mimeType’s essence starts with "audio/", "image/", or "video/".
   • mimeType’s essence is "text/csv".

5. Return allowed.

3. HTTP extensions

3.1. `Origin` header

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

The `Origin` header is a version of the `Referer` [sic] header that does not reveal a path. It is used for all HTTP fetches whose request’s response tainting is "cors", as well as those where request’s method is neither `GET` nor `HEAD`. Due to compatibility constraints it is not included in all fetches.

Its value ABNF:

Origin                           = origin-or-null

origin-or-null                   = origin / %s"null" ; case-sensitive
origin                           = scheme "://" host [ ":" port ]

This supplants the definition in The Web Origin Concept. [ORIGIN]

To append a request `Origin` header, given a request request, run these steps:

1. Let serializedOrigin be the result of byte-serializing a request origin with request.

2. If request’s response tainting is "cors" or request’s mode is "websocket", then append (`Origin`, serializedOrigin) to request’s header list.

3. Otherwise, if request’s method is neither `GET` nor `HEAD`, then:

   1. Switch on request’s referrer policy:

      "no-referrer"

      Set serializedOrigin to `null`.

      "no-referrer-when-downgrade"

      "strict-origin"

      "strict-origin-when-cross-origin"

      If request’s origin is a tuple origin, its scheme is "https", and request’s current URL’s scheme is not "https", then set serializedOrigin to `null`.

      "same-origin"

      If request’s origin is not same origin with request’s current URL’s origin, then set serializedOrigin to `null`.

      Otherwise

      Do nothing.

   2. Append (`Origin`, serializedOrigin) to request’s header list.

A request’s referrer policy is taken into account for all fetches where the fetcher did not explicitly opt into sharing their origin with the server, e.g., via using the CORS protocol.

3.2. CORS protocol

To allow sharing responses cross-origin and allow for more versatile fetches than possible with HTML’s form element, the CORS protocol exists. It is layered on top of HTTP and allows responses to declare they can be shared with other origins.

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

This section explains the CORS protocol as it pertains to server developers. Requirements for user agents are part of the fetch algorithm, except for the new HTTP header syntax.

3.2.1. General

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

For requests that are more involved than what is possible with HTML’s form element, a CORS-preflight request is performed, to ensure request’s current URL supports the CORS protocol.

3.2.2. HTTP requests

A CORS request is an HTTP request that includes an `Origin` header. It cannot be reliably identified as participating in the CORS protocol as the `Origin` header is also included for all requests whose method is neither `GET` nor `HEAD`.

A CORS-preflight request is a CORS request that checks to see if the CORS protocol is understood. It uses `OPTIONS` as method and includes these headers:

✔MDN

Headers/Access-Control-Request-Method

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Request-Method`

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

✔MDN

Headers/Access-Control-Request-Headers

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Request-Headers`

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

3.2.3. HTTP responses

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

✔MDN

Headers/Access-Control-Allow-Origin

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Allow-Origin`

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

✔MDN

Headers/Access-Control-Allow-Credentials

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Allow-Credentials`

Indicates whether the response can be shared when request’s credentials mode is "include".

For a CORS-preflight request, request’s credentials mode is always "same-origin", i.e., it excludes credentials, 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:

✔MDN

Headers/Access-Control-Allow-Methods

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Allow-Methods`

Indicates which methods are supported by the response’s URL for the purposes of the CORS protocol.

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

✔MDN

Headers/Access-Control-Allow-Headers

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Allow-Headers`

Indicates which headers are supported by the response’s URL for the purposes of the CORS protocol.

✔MDN

Headers/Access-Control-Max-Age

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Max-Age`

Indicates the number of seconds (5 by default) 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:

✔MDN

Headers/Access-Control-Expose-Headers

In all current engines.

Firefox3.5+Safari4+Chrome4+

---

Opera12+Edge79+

---

Edge (Legacy)12+IE10+

---

Firefox for Android4+iOS Safari3.2+Chrome for AndroidYesAndroid WebView2+Samsung InternetYesOpera Mobile12+

`Access-Control-Expose-Headers`

Indicates which headers can be exposed as part of the response by listing their names.

A successful HTTP response, i.e., one where the server developer intends to share it, to a CORS request can use any status, as long as it includes the headers stated above with values matching up with the request.

A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204.

Any other kind of HTTP response is not successful and will either end up not being shared or fail the CORS-preflight request. Be aware that any work the server performs might nonetheless leak through side channels, such as timing. If server developers wish to denote this explicitly, the 403 status can be used, coupled with omitting the relevant headers.

If desired, “failure” could also be shared, but that would make it a successful HTTP response. That is why for a successful HTTP response to a CORS request that is not a CORS-preflight requests the status can be anything, including 403.

Ultimately server developers have a lot of freedom in how they handle HTTP responses and these tactics can differ between the response to the CORS-preflight request and the CORS request that follows it:

• They can provide a static response. This can be helpful when working with caching intermediaries. A static response can both be successful and not successful depending on the CORS request. This is okay.

• They can provide a dynamic response, tuned to CORS request. This can be helpful when the response body is to be tailored to a specific origin or a response needs to have credentials and be successful for a set of origins.

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   = 1#field-name

wildcard                         = "*"
Access-Control-Allow-Origin      = origin-or-null / wildcard
Access-Control-Allow-Credentials = %s"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

For `Access-Control-Expose-Headers`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers` response headers, the value `*` counts as a wildcard for requests without credentials. For such requests there is no way to solely match a header name or method that is `*`.

3.2.5. CORS protocol and credentials

When request’s credentials mode is "include" it has an impact on the functioning of the CORS protocol other than including credentials in the fetch.

var client = new XMLHttpRequest()
client.open("GET", "./")
client.withCredentials = true
/* … */

A request’s credentials mode is not necessarily observable on the server; only when credentials exist for a request can it be observed by virtue of the credentials being included. Note that even so, a CORS-preflight request never includes credentials.

The server developer therefore needs to decide whether or not responses "tainted" with credentials can be shared. And also needs to decide if requests necessitating a CORS-preflight request can include credentials. Generally speaking, both sharing responses and allowing requests with credentials is rather unsafe, and extreme care has to be taken to avoid the confused deputy problem.

To share responses with credentials, the `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` headers are important. The following table serves to illustrate the various legal and illegal combinations for a request to https://rabbit.invalid/:

Similarly, `Access-Control-Expose-Headers`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers` response headers can only use `*` as value when request’s credentials mode is not "include".

3.2.6. Examples

var url = "https://bar.invalid/api?key=730d67a37d7f3d802e96396d00280768773813fbe726d116944d814422fc1a45&data=about:unicorn";
fetch(url).then(success, failure)

Origin: https://foo.invalid

fetch(url).then(response => {
  var hsts = response.headers.get("strict-transport-security"),
      csp = response.headers.get("content-security-policy")
  log(hsts, csp)
})

Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Access-Control-Expose-Headers: Content-Security-Policy

fetch(url, { credentials:"include" }).then(success, failure)

Access-Control-Allow-Origin: https://foo.invalid
Access-Control-Allow-Credentials: true

3.2.7. CORS protocol exceptions

Specifications have allowed limited exceptions to the CORS safelist for non-safelisted `Content-Type` header values. These exceptions are made for requests that can be triggered by web content but whose headers and bodies can be only minimally controlled by the web content. Therefore, servers should expect cross-origin web content to be allowed to trigger non-preflighted requests with the following non-safelisted `Content-Type` header values:

• `application/csp-report` [CSP]
• `application/expect-ct-report+json` [EXPECT-CT]
• `application/xss-auditor-report`
• `application/ocsp-request` [OCSP]

Specifications should avoid introducing new exceptions and should only do so with careful consideration for the security consequences. New exceptions can be proposed by filing an issue.

3.3. `Content-Length` header

The `Content-Length` header is largely defined in HTTP. Its processing model is defined here as the model defined in HTTP is not compatible with web content. [HTTP]

To extract a length from a header list headers, run these steps:

1. Let values be the result of getting, decoding, and splitting `Content-Length` from headers.

2. If values is null, then return null.

3. Let candidateValue be null.

4. For each value of values:

   1. If candidateValue is null, then set candidateValue to value.

   2. Otherwise, if value is not candidateValue, return failure.

5. If candidateValue is the empty string or has a code point that is not an ASCII digit, then return null.

6. Return candidateValue, interpreted as decimal number.

3.4. `Content-Type` header

The `Content-Type` header is largely defined in HTTP. Its processing model is defined here as the model defined in HTTP is not compatible with web content. [HTTP]

To extract a MIME type from a header list headers, run these steps:

1. Let charset be null.

2. Let essence be null.

3. Let mimeType be null.

4. Let values be the result of getting, decoding, and splitting `Content-Type` from headers.

5. If values is null, then return failure.

6. For each value of values:

   1. Let temporaryMimeType be the result of parsing value.

   2. If temporaryMimeType is failure or its essence is "*/*", then continue.

   3. Set mimeType to temporaryMimeType.

   4. If mimeType’s essence is not essence, then:

      1. Set charset to null.

      2. If mimeType’s parameters["charset"] exists, then set charset to mimeType’s parameters["charset"].

      3. Set essence to mimeType’s essence.

   5. Otherwise, if mimeType’s parameters["charset"] does not exist, and charset is non-null, set mimeType’s parameters["charset"] to charset.

7. If mimeType is null, then return failure.

8. Return mimeType.

When extract a MIME type returns failure or a MIME type whose essence is incorrect for a given format, treat this as a fatal error. Existing web platform features have not always followed this pattern, which has been a major source of security vulnerabilities in those features over the years. In contrast, a MIME type’s parameters can typically be safely ignored.

Content-Type: text/plain;charset=gbk, text/html

Content-Type: text/html;charset=gbk;a=b, text/html;x=y

Content-Type: text/html;charset=gbk;a=b
Content-Type: text/html;x=y

Content-Type: text/html;charset=gbk
Content-Type: x/x
Content-Type: text/html;x=y

Content-Type: text/html
Content-Type: cannot-parse

Content-Type: text/html
Content-Type: */*

Content-Type: text/html
Content-Type:

3.5. `X-Content-Type-Options` header

The `X-Content-Type-Options` response header can be used to require checking of a response’s `Content-Type` header against the destination of a request.

To determine nosniff, given a header list list, run these steps:

1. Let values be the result of getting, decoding, and splitting `X-Content-Type-Options` from list.

2. If values is null, then return false.

3. If values[0] is an ASCII case-insensitive match for "nosniff", then return true.

4. Return false.

Web developers and conformance checkers must use the following value ABNF for `X-Content-Type-Options`:

X-Content-Type-Options           = "nosniff" ; case-insensitive

3.5.1. Should response to request be blocked due to nosniff?

Run these steps:

1. If determine nosniff with response’s header list is false, then return allowed.

2. Let mimeType be the result of extracting a MIME type from response’s header list.

3. Let destination be request’s destination.

4. If destination is script-like and mimeType is failure or is not a JavaScript MIME type, then return blocked.

5. If destination is "style" and mimeType is failure or its essence is not "text/css", then return blocked.

6. Return allowed.

Only request destinations that are script-like or "style" are considered as any exploits pertain to them. Also, considering "image" was not compatible with deployed content.

3.6. CORB

Cross-origin read blocking, better known as CORB, is an algorithm which identifies dubious cross-origin resource fetches (e.g., fetches that would fail anyway like attempts to render JSON inside an img element) and blocks them before they reach a web page. CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages.

A CORB-protected MIME type is an HTML MIME type, a JSON MIME type, or an XML MIME type excluding image/svg+xml.

Even without CORB, accessing the content of cross-origin resources with CORB-protected MIME types is either managed by the CORS protocol (e.g., in case of XMLHttpRequest), not observable (e.g., in case of pings or CSP reports which ignore the response), or would result in an error (e.g., when failing to decode an HTML document embedded in an img element as an image). This means that CORB can block CORB-protected MIME types resources without being disruptive to web pages.

To perform a CORB check, given a request and response, run these steps:

1. If request’s initiator is "download", then return allowed.

   If we recast downloading as navigation this step can be removed.

2. If request’s current URL’s scheme is not an HTTP(S) scheme, then return allowed.

3. Let mimeType be the result of extracting a MIME type from response’s header list.

4. If mimeType is failure, then return allowed.

5. If response’s status is 206 and mimeType is a CORB-protected MIME type, then return blocked.

6. If determine nosniff with response’s header list is true and mimeType is a CORB-protected MIME type or its essence is "text/plain", then return blocked.

   CORB only protects text/plain responses with a `X-Content-Type-Options: nosniff` header. Unfortunately, protecting such responses without that header when their status is 206 would break too many existing video responses that have a text/plain MIME type.

7. Return allowed.

3.7. `Cross-Origin-Resource-Policy` header

The `Cross-Origin-Resource-Policy` response header can be used to require checking a request’s current URL’s origin against a request’s origin when request’s mode is "no-cors".

Its value ABNF:

Cross-Origin-Resource-Policy     = %s"same-origin" / %s"same-site" / %s"cross-origin" ; case-sensitive

To perform a cross-origin resource policy check, given an origin origin, an environment settings object settingsObject, a string destination, a response response, and an optional boolean forNavigation, run these steps:

1. Set forNavigation to false if it is not given.

2. Let embedderPolicy be settingsObject’s policy container’s embedder policy.

3. If the cross-origin resource policy internal check with origin, "unsafe-none", response, and forNavigation returns blocked, then return blocked.

   This step is needed because we don’t want to report violations not related to Cross-Origin Embedder Policy below.

4. If the cross-origin resource policy internal check with origin, embedderPolicy’s report only value, response, and forNavigation returns blocked, then queue a cross-origin embedder policy CORP violation report with response, settingsObject, destination, and true.

5. If the cross-origin resource policy internal check with origin, embedderPolicy’s value, response, and forNavigation returns allowed, then return allowed.

6. Queue a cross-origin embedder policy CORP violation report with response, settingsObject, destination, and false.

7. Return blocked.

Only HTML’s navigate algorithm uses this check with forNavigation set to true, and it’s always for nested navigations. Otherwise, response is either the internal response of an opaque filtered response or a response which will be the internal response of an opaque filtered response. [HTML]

To perform a cross-origin resource policy internal check, given an origin origin, an embedder policy value embedderPolicyValue, a response response, and a boolean forNavigation, run these steps:

1. If forNavigation is true and embedderPolicyValue is "unsafe-none", then return allowed.

2. Let policy be the result of getting `Cross-Origin-Resource-Policy` from response’s header list.

   This means that `Cross-Origin-Resource-Policy: same-site, same-origin` ends up as allowed below as it will never match anything, as long as embedderPolicyValue is "unsafe-none". Two or more `Cross-Origin-Resource-Policy` headers will have the same effect.

3. If policy is neither `same-origin`, `same-site`, nor `cross-origin`, then set policy to null.

4. If policy is null and embedderPolicyValue is "require-corp", then set policy to `same-origin`.

5. Switch on policy:

   null

   `cross-origin`

   Return allowed.

   `same-origin`

   If origin is same origin with response’s URL’s origin, then return allowed.

   Otherwise, return blocked.

   `same-site`

   If all of the following are true

   • origin is schemelessly same site with response’s URL’s origin

   • origin’s scheme is "https" or response’s URL’s scheme is not "https"

   then return allowed.

   Otherwise, return blocked.

   `Cross-Origin-Resource-Policy: same-site` does not consider a response delivered via a secure transport to match a non-secure requesting origin, even if their hosts are otherwise same site. Securely-transported responses will only match a securely-transported initiator.

To queue a cross-origin embedder policy CORP violation report, given a response response, an environment settings object settingsObject, a string destination, and a boolean reportOnly, run these steps:

1. Let endpoint be settingsObject’s policy container’s embedder policy’s report only reporting endpoint if reportOnly is true and settingsObject’s policy container’s embedder policy’s reporting endpoint otherwise.

2. Let serializedURL be the result of serializing a response URL for reporting with response.

3. Let disposition be "reporting" if reportOnly is true; otherwise "enforce".

4. Let body be a new object containing the following properties:

   key	value
   "type"	"corp"
   "blockedURL"	serializedURL
   "destination"	destination
   "disposition"	disposition

5. Queue body as the "coep" report type for endpoint on settingsObject. [REPORTING]

4. Fetching

The algorithm below defines fetching. In broad strokes, it takes a request and one or more algorithms to run at various points during the operation. A response is passed to the last two algorithms listed below. The first two algorithms can be used to capture uploads.

To fetch, given a request request, an optional algorithm processRequestBodyChunkLength, an optional algorithm processRequestEndOfBody, an optional algorithm processResponse, an optional algorithm processResponseEndOfBody, an optional algorithm processResponseDone, and an optional boolean useParallelQueue (default false), run the steps below. If given, processRequestBodyChunkLength must be an algorithm accepting an integer representing the number of bytes transmitted. If given, processRequestEndOfBody must be an algorithm accepting no arguments. If given, processResponse must be an algorithm accepting a response. If given, processResponseEndOfBody must be an algorithm accepting a response and null, failure, or a byte sequence. If given, processResponseDone must be an algorithm accepting a response.

An ongoing fetch can be terminated with flag aborted, which is unset unless otherwise specified.

The user agent may be asked to suspend the ongoing fetch. The user agent may either accept or ignore the suspension request. The suspended fetch can be resumed. The user agent should ignore the suspension request if the ongoing fetch is updating the response in the HTTP cache for the request.

The user agent does not update the entry in the HTTP cache for a request if request’s cache mode is "no-store" or a `Cache-Control: no-store` header appears in the response. [HTTP-CACHING]

1. Let taskDestination be null.

2. Let crossOriginIsolatedCapability be false.

3. If request’s client is non-null, then:

   1. Set taskDestination to request’s client’s global object.

   2. Set crossOriginIsolatedCapability to request’s client’s cross-origin isolated capability.

4. If useParallelQueue is true, then set taskDestination to the result of starting a new parallel queue.

5. Let timingInfo be a new fetch timing info whose start time and post-redirect start time are the coarsened shared current time given crossOriginIsolatedCapability.

6. Let fetchParams be a new fetch params whose request is request, timing info is timingInfo, process request body chunk length is processRequestBodyChunkLength, process request end-of-body is processRequestEndOfBody, process response is processResponse, process response end-of-body is processResponseEndOfBody, process response done is processResponseDone, task destination is taskDestination, and cross-origin isolated capability is crossOriginIsolatedCapability.

7. If request’s body is a byte sequence, then set request’s body to the first return value of safely extracting request’s body.

8. If request’s window is "client", then set request’s window to request’s client, if request’s client’s global object is a Window object; otherwise "no-window".

9. If request’s origin is "client", then set request’s origin to request’s client’s origin.

10. If request’s policy container is "client", then:

    1. If request’s client is non-null, then set request’s policy container to a clone of request’s client’s policy container. [HTML]

    2. Otherwise, set request’s policy container to a new policy container.

11. If request’s header list does not contain `Accept`, then:

    1. Let value be `*/*`.

    2. A user agent should set value to the first matching statement, if any, switching on request’s destination:

       "document"

       "frame"

       "iframe"

       `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8`

       "image"

       `image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5`

       "style"

       `text/css,*/*;q=0.1`

    3. Append (`Accept`, value) to request’s header list.

12. If request’s header list does not contain `Accept-Language`, then user agents should append (`Accept-Language, an appropriate header value) to request’s header list.

13. If request’s priority is null, then use request’s initiator and destination appropriately in setting request’s priority to a user-agent-defined object.

    The user-agent-defined object could encompass stream weight and dependency for HTTP/2, and equivalent information used to prioritize dispatch and processing of HTTP/1 fetches.

14. If request is a subresource request, then:

    1. Let record be a new fetch record consisting of request and this instance of the fetch algorithm.

    2. Append record to request’s client’s fetch group list of fetch records.

15. Run main fetch given fetchParams.

4.1. Main fetch

To main fetch, given a fetch params fetchParams and an optional boolean recursive (default false), run these steps:

1. Let request be fetchParams’s request.

2. Let response be null.

3. If request’s local-URLs-only flag is set and request’s current URL is not local, then set response to a network error.

4. Run report Content Security Policy violations for request.

5. Upgrade request to a potentially trustworthy URL, if appropriate.

6. If should request be blocked due to a bad port, should fetching request be blocked as mixed content, or should request be blocked by Content Security Policy returns blocked, then set response to a network error.

7. If request’s referrer policy is the empty string, then set request’s referrer policy to request’s policy container’s referrer policy.

8. If request’s referrer is not "no-referrer", then set request’s referrer to the result of invoking determine request’s referrer. [REFERRER]

   As stated in Referrer Policy, user agents can provide the end user with options to override request’s referrer to "no-referrer" or have it expose less sensitive information.

9. Set request’s current URL’s scheme to "https" if all of the following conditions are true:

   • request’s current URL’s scheme is "http"
   • request’s current URL’s host is a domain
   • Matching request’s current URL’s host per Known HSTS Host Domain Name Matching results in either a superdomain match with an asserted includeSubDomains directive or a congruent match (with or without an asserted includeSubDomains directive). [HSTS]

10. If recursive is false, then run the remaining steps in parallel.

11. If response is null, then set response to the result of running the steps corresponding to the first matching statement:

    request’s current URL’s origin is same origin with request’s origin, and request’s response tainting is "basic"

    request’s current URL’s scheme is "data"

    request’s mode is "navigate" or "websocket"

    1. Set request’s response tainting to "basic".

    2. Return the result of running scheme fetch given fetchParams.

    HTML assigns any documents and workers created from URLs whose scheme is "data" a unique opaque origin. Service workers can only be created from URLs whose scheme is an HTTP(S) scheme. [HTML] [SW]

    request’s mode is "same-origin"

    Return a network error.

    request’s mode is "no-cors"

    1. If request’s redirect mode is not "follow", then return a network error.

    2. Set request’s response tainting to "opaque".

    3. Let noCorsResponse be the result of running scheme fetch given fetchParams.

    4. If noCorsResponse is a filtered response or the CORB check with request and noCorsResponse returns allowed, then return noCorsResponse.

    5. Return a new response whose status is noCorsResponse’s status.

       This is only an effective defense against side channel attacks if noCorsResponse is kept isolated from the process that initiated the request.

    request’s current URL’s scheme is not an HTTP(S) scheme

    Return a network error.

    request’s use-CORS-preflight flag is set

    request’s unsafe-request flag is set and either request’s method is not a CORS-safelisted method or CORS-unsafe request-header names with request’s header list is not empty

    1. Set request’s response tainting to "cors".

    2. Let corsWithPreflightResponse be the result of running HTTP fetch given fetchParams and true.

    3. If corsWithPreflightResponse is a network error, then clear cache entries using request.

    4. Return corsWithPreflightResponse.

    Otherwise

    1. Set request’s response tainting to "cors".

    2. Return the result of running HTTP fetch given fetchParams.

12. If recursive is true, then return response.

13. If response is not a network error and response is not a filtered response, then:

    1. If request’s response tainting is "cors", then:

       1. Let headerNames be the result of extracting header list values given `Access-Control-Expose-Headers` and response’s header list.

       2. If request’s credentials mode is not "include" and headerNames contains `*`, then set response’s CORS-exposed header-name list to all unique header names in response’s header list.

       3. Otherwise, if headerNames is not null or failure, then set response’s CORS-exposed header-name list to headerNames.

          One of the headerNames can still be `*` at this point, but will only match a header whose name is `*`.

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

14. Let internalResponse be response, if response is a network error, and response’s internal response otherwise.

15. If internalResponse’s URL list is empty, then set it to a clone of request’s URL list.

    A response’s URL list can be empty (for example, when the response represents an about URL).

16. If request’s timing allow failed flag is unset, then set internalResponse’s timing allow passed flag.

17. If response is not a network error and any of the following returns blocked

    • should internalResponse to request be blocked as mixed content

    • should internalResponse to request be blocked by Content Security Policy

    • should internalResponse to request be blocked due to its MIME type

    • should internalResponse to request be blocked due to nosniff

    then set response and internalResponse to a network error.

18. If response’s type is "opaque", internalResponse’s status is 206, internalResponse’s range-requested flag is set, and request’s header list does not contain `Range`, then set response and internalResponse to a network error.

    Traditionally, APIs accept a ranged response even if a range was not requested. This prevents a partial response from an earlier ranged request being provided to an API that did not make a range request.

    Further details

    The above steps prevent the following attack:

    A media element is used to request a range of a cross-origin HTML resource. Although this is invalid media, a reference to a clone of the response can be retained in a service worker. This can later be used as the response to a script element’s fetch. If the partial response is valid JavaScript (even though the whole resource is not), executing it would leak private data.

19. If response is not a network error and either request’s method is `HEAD` or `CONNECT`, or internalResponse’s status is a null body status, set internalResponse’s body to null and disregard any enqueuing toward it (if any).

    This standardizes the error handling for servers that violate HTTP.

20. If request’s integrity metadata is not the empty string, then:

    1. Let processBodyError be this step: run fetch finale given fetchParams and a network error.

    2. If request’s response tainting is "opaque", response is a network error, or response’s body is null, then run processBodyError and abort these steps.

    3. Let processBody given bytes be these steps:

       1. If bytes do not match request’s integrity metadata, then run processBodyError and abort these steps. [SRI]

       2. Set response’s body to the first return value of safely extracting bytes.

       3. Run fetch finale given fetchParams and response.

    4. Fully read response’s body given processBody and processBodyError.

21. Otherwise, run fetch finale given fetchParams and response.

The fetch finale, given a fetch params fetchParams and a response response, run these steps:

1. If fetchParams’s process response is non-null, then queue a fetch task to run fetchParams’s process response given response, with fetchParams’s task destination.

2. If fetchParams’s process response end-of-body is non-null, then:

   1. Let processBody given nullOrBytes be this step: run fetchParams’s process response end-of-body given response and nullOrBytes.

   2. Let processBodyError be this step: run fetchParams’s process response end-of-body given response and failure.

   3. If response’s body is null, then queue a fetch task to run processBody given null, with fetchParams’s task destination.

   4. Otherwise, fully read response’s body given processBody, processBodyError, and fetchParams’s task destination.

To finalize response given a fetch params fetchParams and a response response, run these steps:

1. Set fetchParams’s request’s done flag.

2. If fetchParams’s process response done is not null, then queue a fetch task to run fetchParams’s process response done given response, with fetchParams’s task destination.

To finalize and report timing given a response response, a global object global, and a string initiatorType (default "other"), run these steps:

1. If response’s URL list is null or empty, then return.

2. Let originalURL be response’s URL list[0].

3. Let timingInfo be response’s timing info.

4. Let cacheState be response’s cache state.

5. If timingInfo is null, then return.

6. If response’s timing allow passed flag is not set, then:

   1. Set timingInfo to a the result of creating an opaque timing info for timingInfo.

   2. Set cacheState to the empty string.

7. Set timingInfo’s end time to the coarsened shared current time given global’s relevant settings object’s cross-origin isolated capability.

8. Set response’s timing info to timingInfo.

9. Mark resource timing for timingInfo, originalURL, initiatorType, global, and cacheState.

4.2. Scheme fetch

To scheme fetch, given a fetch params fetchParams: let request be fetchParams’s request, switch on request’s current URL’s scheme, and run the associated steps:

"about"

If request’s current URL’s path is the string "blank", then return a new response whose status message is `OK`, header list is « (`Content-Type`, `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"

1. Run these steps, but abort when the ongoing fetch is terminated:

   1. Let blob be request’s current URL’s blob URL entry’s object.

   2. If request’s method is not `GET` or blob is not a Blob object, then return a network error. [FILEAPI]

      The `GET` method restriction serves no useful purpose other than being interoperable.

   3. Let response be a new response whose status message is `OK`.

   4. Append (`Content-Length`, blob’s size attribute value) to response’s header list.

   5. Append (`Content-Type`, blob’s type attribute value) to response’s header list.

   6. Set response’s body to the result of performing the read operation on blob.

   7. Return response.

2. If aborted, then:

   1. Let aborted be the termination’s aborted flag.

   2. If aborted is set, then return an aborted network error.

   3. Return a network error.

"data"

1. Let dataURLStruct be the result of running the data: URL processor on request’s current URL.

2. If dataURLStruct is failure, then return a network error.

3. Let mimeType be dataURLStruct’s MIME type, serialized.

4. Return a response whose status message is `OK`, header list is « (`Content-Type`, mimeType) », and body is dataURLStruct’s body.

"file"

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

When in doubt, return a network error.

HTTP(S) scheme

Return the result of running HTTP fetch given fetchParams.

Otherwise

Return a network error.

4.3. HTTP fetch

To HTTP fetch, given a fetch params fetchParams and an optional boolean makeCORSPreflight (default false), run these steps:

1. Let request be fetchParams’s request.

2. Let response be null.

3. Let actualResponse be null.

4. Let timingInfo be fetchParams’s timing info.

5. If request’s service-workers mode is "all", then:

   1. Let requestForServiceWorker be a clone of request.

   2. If requestForServiceWorker’s body is non-null, then:

      1. Let transformAlgorithm given chunk be these steps:

         1. If the ongoing fetch is terminated, then abort these steps.

         2. If chunk is not a Uint8Array object, then terminate the ongoing fetch.

         3. Otherwise, enqueue chunk. The user agent may split the chunk into implementation-defined practical sizes and enqueue each of them. The user agent also may concatenate the chunks into an implementation-defined practical size and enqueue it.

      2. Let transformStream be the result of setting up a TransformStream with transformAlgorithm.

      3. Let transformedStream be the result of requestForServiceWorker’s body’s stream piped through transformStream.

      4. Set requestForServiceWorker’s body’s stream to transformedStream.

   3. Let serviceWorkerStartTime be the coarsened shared current time given fetchParams’s cross-origin isolated capability.

   4. Set response to the result of invoking handle fetch for requestForServiceWorker. [HTML] [SW]

   5. If response is not null, then:

      1. Set fetchParams’s timing info’s final service worker start time to serviceWorkerStartTime.

      2. Update timing info from stored response given fetchParams’s timing info and response.

      3. If request’s body is non-null, then cancel request’s body with undefined.

      4. Set actualResponse to response, if response is not a filtered response, and to response’s internal response otherwise.

      5. If one of the following is true

         • response’s type is "error"

         • request’s mode is "same-origin" and response’s type is "cors"

         • request’s mode is not "no-cors" and response’s type is "opaque"

         • request’s redirect mode is not "manual" and response’s type is "opaqueredirect"
         • request’s redirect mode is not "follow" and response’s URL list has more than one item.

         then return a network error.

6. If response is null, then:

   1. If makeCORSPreflight is true and one of these conditions is true:

      • There is no method cache entry match for request’s method using request, and either request’s method is not a CORS-safelisted method or request’s use-CORS-preflight flag is set.

      • There is at least one item in the CORS-unsafe request-header names with request’s header list for which there is no header-name cache entry match using request.

      Then:

      1. Let preflightResponse be the result of running CORS-preflight fetch given request.

      2. If preflightResponse is a network error, then return preflightResponse.

      This step checks the CORS-preflight cache and if there is no suitable entry it performs a CORS-preflight fetch which, if successful, populates the cache. The purpose of the CORS-preflight fetch is to ensure the fetched resource is familiar with the CORS protocol. The cache is there to minimize the number of CORS-preflight fetches.

   2. If request’s redirect mode is "follow", then set request’s service-workers mode to "none".

      Redirects coming from the network (as opposed to from a service worker) are not to be exposed to a service worker.

   3. Set response and actualResponse to the result of running HTTP-network-or-cache fetch given fetchParams.

   4. If request’s response tainting is "cors" and a CORS check for request and response returns failure, then return a network error.

      As the CORS check is not to be applied to responses whose status is 304 or 407, or responses from a service worker for that matter, it is applied here.

   5. If the TAO check for request and response returns failure, then set request’s timing allow failed flag.

7. If either request’s response tainting or response’s type is "opaque", and the cross-origin resource policy check with request’s origin, request’s client, request’s destination, and actualResponse returns blocked, then return a network error.

   The cross-origin resource policy check runs for responses coming from the network and responses coming from the service worker. This is different from the CORS check, as request’s client and the service worker can have different embedder policies.

8. If actualResponse’s status is a redirect status, then:

   1. If actualResponse’s status is not 303, request’s body is not null, and the connection uses HTTP/2, then user agents may, and are even encouraged to, transmit an RST_STREAM frame.

      303 is excluded as certain communities ascribe special status to it.

   2. Switch on request’s redirect mode:

      "error"

      Set response to a network error.

      "manual"

      Set response to an opaque-redirect filtered response whose internal response is actualResponse.

      "follow"

      Set response to the result of running HTTP-redirect fetch given fetchParams and response.

9. Set response’s timing info to timingInfo.

   Attaching the timing info to a response is what makes it exposed to the web as a Resource Timing entry later. This step is done here, as resource-timing entries are available only for HTTP fetches, including ones that are handled by service-workers or HTTP cache, and not for, e.g., data:, blob: URL fetches, and are only available after all the relevant security checks have succeeded.

10. Return response. Typically actualResponse’s body’s stream is still being enqueued to after returning.

4.4. HTTP-redirect fetch

To HTTP-redirect fetch, given a fetch params fetchParams and a response response, run these steps:

1. Let request be fetchParams’s request.

2. Let actualResponse be response, if response is not a filtered response, and response’s internal response otherwise.

3. Let locationURL be actualResponse’s location URL given request’s current URL’s fragment.

4. If locationURL is null, then return response.

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

6. If locationURL’s scheme is not an HTTP(S) scheme, then return a network error.

7. If request’s redirect count is twenty, return a network error.

8. Increase request’s redirect count by one.

9. If request’s mode is "cors", locationURL includes credentials, and request’s origin is not same origin with locationURL’s origin, then return a network error.

10. If request’s response tainting is "cors" and locationURL includes credentials, then return a network error.

    This catches a cross-origin resource redirecting to a same-origin URL.

11. If actualResponse’s status is not 303, request’s body is non-null, and request’s body’s source is null, then return a network error.

12. If locationURL’s origin is not same origin with request’s current URL’s origin and request’s origin is not same origin with request’s current URL’s origin, then set request’s tainted origin flag.

13. If one of the following is true

    • actualResponse’s status is 301 or 302 and request’s method is `POST`

    • actualResponse’s status is 303 and request’s method is not `GET` or `HEAD`

    then:

    1. Set request’s method to `GET` and request’s body to null.

    2. For each headerName of request-body-header name, delete headerName from request’s header list.

14. If request’s body is non-null, then set request’s body to the first return value of safely extracting request’s body’s source.

    request’s body’s source’s nullity has already been checked.

15. Let timingInfo be fetchParams’s timing info.

16. Set timingInfo’s redirect end time and post-redirect start time to the coarsened shared current time given fetchParams’s cross-origin isolated capability.

17. If timingInfo’s redirect start time is 0, then set timingInfo’s redirect start time to timingInfo’s start time.

18. Append locationURL to request’s URL list.

19. Invoke set request’s referrer policy on redirect on request and actualResponse. [REFERRER]

20. Return the result of running main fetch given fetchParams and true.

    This has to invoke main fetch to get request’s response tainting correct.

4.5. Navigate-redirect fetch

This algorithm is used by HTML’s navigate algorithm. It is expected to be invoked while in parallel. [HTML]

To navigate-redirect fetch, given a request request and response response, run these steps. They return a response.

1. Assert: request’s redirect mode is "manual".

2. Let fetchParams be a new fetch params whose request is request.

3. Return the result of running HTTP-redirect fetch given fetchParams and response.

4.6. HTTP-network-or-cache fetch

To HTTP-network-or-cache fetch, given a fetch params fetchParams, an optional boolean isAuthenticationFetch (default false), and an optional boolean isNewConnectionFetch (default false), run these steps:

Some implementations might support caching of partial content, as per HTTP Range Requests. However, this is not widely supported by browser caches. [HTTP-RANGE]

1. Let request be fetchParams’s request.

2. Let httpFetchParams be null.

3. Let httpRequest be null.

4. Let response be null.

5. Let storedResponse be null.

6. Let httpCache be null.

7. Let the revalidatingFlag be unset.

8. Run these steps, but abort when the ongoing fetch is terminated:

   1. If request’s window is "no-window" and request’s redirect mode is "error", then set httpFetchParams to fetchParams and httpRequest to request.

   2. Otherwise:

      1. Set httpRequest to a clone of request.

         Implementations are encouraged to avoid teeing request’s body’s stream when request’s body’s source is null as only a single body is needed in that case. E.g., when request’s body’s source is null, redirects and authentication will end up failing the fetch.

      2. Set httpFetchParams to a copy of fetchParams.

      3. Set httpFetchParams’s request to httpRequest.

   3. Let includeCredentials be true if one of

      • request’s credentials mode is "include"
      • request’s credentials mode is "same-origin" and request’s response tainting is "basic"

      is true; otherwise false.

   4. Let contentLength be httpRequest’s body’s length, if httpRequest’s body is non-null; otherwise null.

   5. Let contentLengthHeaderValue be null.

   6. If httpRequest’s body is null and httpRequest’s method is `POST` or `PUT`, then set contentLengthHeaderValue to `0`.

   7. If contentLength is non-null, then set contentLengthHeaderValue to contentLength, serialized and isomorphic encoded.

   8. If contentLengthHeaderValue is non-null, then append (`Content-Length`, contentLengthHeaderValue) to httpRequest’s header list.

   9. If contentLength is non-null and httpRequest’s keepalive is true, then:

      1. Let inflightKeepaliveBytes be 0.

      2. Let group be httpRequest’s client’s fetch group.

      3. Let inflightRecords be the set of fetch records in group whose request’s keepalive is true and done flag is unset.

      4. For each fetchRecord in inflightRecords:

         1. Let inflightRequest be fetchRecord’s request.

         2. Increment inflightKeepaliveBytes by inflightRequest’s body’s length.

      5. If the sum of contentLength and inflightKeepaliveBytes is greater than 64 kibibytes, then return a network error.

      The above limit ensures that requests that are allowed to outlive the environment settings object and contain a body, have a bounded size and are not allowed to stay alive indefinitely.

   10. If httpRequest’s referrer is a URL, then:

       1. Let referrerValue be httpRequest’s referrer, serialized and isomorphic encoded.

       2. Append (`Referer`, referrerValue) to httpRequest’s header list.

   11. Append a request `Origin` header for httpRequest.

   12. Append the Fetch metadata headers for httpRequest. [FETCH-METADATA]

   13. If httpRequest’s header list does not contain `User-Agent`, then user agents should append (`User-Agent`, default `User-Agent` value) to httpRequest’s header list.

   14. If httpRequest’s cache mode is "default" and httpRequest’s header list contains `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match`, or `If-Range`, then set httpRequest’s cache mode to "no-store".

   15. If httpRequest’s cache mode is "no-cache", httpRequest’s prevent no-cache cache-control header modification flag is unset, and httpRequest’s header list does not contain `Cache-Control`, then append (`Cache-Control`, `max-age=0`) to httpRequest’s header list.

   16. If httpRequest’s cache mode is "no-store" or "reload", then:

       1. If httpRequest’s header list does not contain `Pragma`, then append (`Pragma`, `no-cache`) to httpRequest’s header list.

       2. If httpRequest’s header list does not contain `Cache-Control`, then append (`Cache-Control`, `no-cache`) to httpRequest’s header list.

   17. If httpRequest’s header list contains `Range`, then append (`Accept-Encoding`, `identity`) to httpRequest’s header list.

       This avoids a failure when handling content codings with a part of an encoded response.

       Additionally, many servers mistakenly ignore `Range` headers if a non-identity encoding is accepted.

   18. Modify httpRequest’s header list per HTTP. Do not append a given header if httpRequest’s header list contains that header’s name.

       It would be great if we could make this more normative somehow. At this point headers such as `Accept-Encoding`, `Connection`, `DNT`, and `Host`, are to be appended if necessary.

       `Accept`, `Accept-Charset`, and `Accept-Language` must not be included at this point.

       `Accept` and `Accept-Language` are already included (unless fetch() is used, which does not include the latter by default), and `Accept-Charset` is a waste of bytes. See HTTP header layer division for more details.

   19. If includeCredentials is true, then:

       1. If the user agent is not configured to block cookies for httpRequest (see section 7 of [COOKIES]), then:

          1. Let cookies be the result of running the "cookie-string" algorithm (see section 5.4 of [COOKIES]) with the user agent’s cookie store and httpRequest’s current URL.

          2. If cookies is not the empty string, then append (`Cookie`, cookies) to httpRequest’s header list.

       2. If httpRequest’s header list does not contain `Authorization`, then:

          1. Let authorizationValue be null.

          2. If there’s an authentication entry for httpRequest and either httpRequest’s use-URL-credentials flag is unset or httpRequest’s current URL does not include credentials, then set authorizationValue to authentication entry.

          3. Otherwise, if httpRequest’s current URL does include credentials and isAuthenticationFetch is true, set authorizationValue to httpRequest’s current URL, converted to an `Authorization` value.

          4. If authorizationValue is non-null, then append (`Authorization`, authorizationValue) to httpRequest’s header list.

   20. If there’s a proxy-authentication entry, use it as appropriate.

       This intentionally does not depend on httpRequest’s credentials mode.

   21. Set httpCache to the result of determining the HTTP cache partition, given httpRequest.

   22. If httpCache is null, then set httpRequest’s cache mode to "no-store".

   23. If httpRequest’s cache mode is neither "no-store" nor "reload", then:

       1. Let timingInfo be fetchParams’s timing info.

          Set storedResponse to the result of selecting a response from the httpCache, possibly needing validation, as per the "Constructing Responses from Caches" chapter of HTTP Caching [HTTP-CACHING], if any.

          As mandated by HTTP, this still takes the `Vary` header into account.

       2. If storedResponse is non-null, then:

          1. If cache mode is "default", storedResponse is a stale-while-revalidate response, and httpRequest’s client is non-null, then:

             1. Set response to storedResponse.

             2. Set response’s cache state to "local".

             3. Let revalidateRequest be a clone of request.

             4. Set revalidateRequest’s cache mode set to "no-cache".

             5. Set revalidateRequest’s prevent no-cache cache-control header modification flag.

             6. Set revalidateRequest’s service-workers mode set to "none".

             7. In parallel, run main fetch given a new fetch params whose request is revalidateRequest.

                This fetch is only meant to update the state of httpCache and the response will be unused until another cache access. The stale response will be used as the response to current request. This fetch is issued in the context of a client so if it goes away the request will be terminated.

          2. Otherwise:

             1. If storedResponse is a stale response, then set the revalidatingFlag.

             2. If the revalidatingFlag is set and httpRequest’s cache mode is neither "force-cache" nor "only-if-cached", then:

                1. If storedResponse’s header list contains `ETag`, then append (`If-None-Match`, `ETag`'s value) to httpRequest’s header list.

                2. If storedResponse’s header list contains `Last-Modified`, then append (`If-Modified-Since`, `Last-Modified`'s value) to httpRequest’s header list.

                See also the "Sending a Validation Request" chapter of HTTP Caching [HTTP-CACHING].

             3. Otherwise, set response to storedResponse and set response’s cache state to "local".

9. If aborted, then:

   1. Let aborted be the termination’s aborted flag.

   2. If aborted is set, then return an aborted network error.

   3. Return a network error.

10. If response is null, then:

    1. If httpRequest’s cache mode is "only-if-cached", then return a network error.

    2. Let forwardResponse be the result of running HTTP-network fetch given httpFetchParams, includeCredentials, and isNewConnectionFetch.

    3. If httpRequest’s method is unsafe and forwardResponse’s status is in the range 200 to 399, inclusive, invalidate appropriate stored responses in httpCache, as per the "Invalidation" chapter of HTTP Caching, and set storedResponse to null. [HTTP-CACHING]

    4. If the revalidatingFlag is set and forwardResponse’s status is 304, then:

       1. Update storedResponse’s header list using forwardResponse’s header list, as per the "Freshening Stored Responses upon Validation" chapter of HTTP Caching. [HTTP-CACHING]

          This updates the stored response in cache as well.

       2. Set response to storedResponse.

       3. Set response’s cache state to "validated".

       4. Update timing info from stored response given fetchParams’s timing info and response.

    5. If response is null, then:

       1. Set response to forwardResponse.

       2. Store httpRequest and forwardResponse in httpCache, as per the "Storing Responses in Caches" chapter of HTTP Caching. [HTTP-CACHING]

          If forwardResponse is a network error, this effectively caches the network error, which is sometimes known as "negative caching".

          The associated timing info is stored in the cache alongside the response.

11. Set response’s URL list to a clone of httpRequest’s URL list.

12. If httpRequest’s header list contains `Range`, then set response’s range-requested flag.

13. If response’s status is 401, httpRequest’s response tainting is not "cors", includeCredentials is true, and request’s window is an environment settings object, then:

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

    2. If request’s body is non-null, then:

       1. If request’s body’s source is null, then return a network error.

       2. Set request’s body to the first return value of safely extracting request’s body’s source.

    3. If request’s use-URL-credentials flag is unset or isAuthenticationFetch is true, then:

       1. If the ongoing fetch is terminated, then:

          1. Let aborted be the termination’s aborted flag.

          2. If aborted is set, then return an aborted network error.

          3. Return a network error.

       2. Let username and password be the result of prompting the end user for a username and password, respectively, in request’s window.

       3. Set the username given request’s current URL and username.

       4. Set the password given request’s current URL and password.

    4. Set response to the result of running HTTP-network-or-cache fetch given fetchParams and true.

14. If response’s status is 407, then:

    1. If request’s window is "no-window", then return a network error.

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

    3. If the ongoing fetch is terminated, then:

       1. Let aborted be the termination’s aborted flag.

       2. If aborted is set, then return an aborted network error.

       3. Return a network error.

    4. Prompt the end user as appropriate in request’s window and store the result as a proxy-authentication entry. [HTTP-AUTH]

       Remaining details surrounding proxy authentication are defined by HTTP.

    5. Set response to the result of running HTTP-network-or-cache fetch given fetchParams.

15. If all of the following are true

    • response’s status is 421

    • isNewConnectionFetch is false

    • request’s body is null, or request’s body is non-null and request’s body’s source is non-null

    then:

    1. If the ongoing fetch is terminated, then:

       1. Let aborted be the termination’s aborted flag.

       2. If aborted is set, then return an aborted network error.

       3. Return a network error.

    2. Set response to the result of running HTTP-network-or-cache fetch given fetchParams, isAuthenticationFetch, and true.

16. If isAuthenticationFetch is true, then create an authentication entry for request and the given realm.

17. Return response. Typically response’s body’s stream is still being enqueued to after returning.

4.7. HTTP-network fetch

To HTTP-network fetch, given a fetch params fetchParams, an optional boolean includeCredentials (default false), and an optional boolean forceNewConnection (default false), run these steps:

1. Let request be fetchParams’s request.

2. Let response be null.

3. Let timingInfo be fetchParams’s timing info.

4. Let httpCache be the result of determining the HTTP cache partition, given request.

5. If httpCache is null, then set request’s cache mode to "no-store".

6. Let networkPartitionKey be the result of determining the network partition key given request.

7. Let newConnection be "yes" if forceNewConnection is true; otherwise "no".

8. Switch on request’s mode:

   "websocket"

   Let connection be the result of obtaining a WebSocket connection, given request’s current URL.

   Otherwise

   Let connection be the result of obtaining a connection, given networkPartitionKey, request’s current URL, includeCredentials, and newConnection.

9. Run these steps, but abort when the ongoing fetch is terminated:

   1. If connection is failure, then return a network error.

   2. Set timingInfo’s final connection timing info to the result of calling clamp and coarsen connection timing info with connection’s timing info, timingInfo’s post-redirect start time, and fetchParams’s cross-origin isolated capability.

   3. If connection is not an HTTP/2 connection, request’s body is non-null, and request’s body’s source is null, then append (`Transfer-Encoding`, `chunked`) to request’s header list.

   4. Set timingInfo’s final network-request start time to the coarsened shared current time given fetchParams’s cross-origin isolated capability.

   5. Set response to the result of making an HTTP request over connection using request with the following caveats:

      • Follow the relevant requirements from HTTP. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]

      • If request’s body is non-null, and request’s body’s source is null, then the user agent may have a buffer of up to 64 kibibytes and store a part of request’s body in that buffer. If the user agent reads from request’s body beyond that buffer’s size and the user agent needs to resend request, then instead return a network error.

        The resending is needed when the connection is timed out, for example.

        The buffer is not needed when request’s body’s source is non-null, because request’s body can be recreated from it.

        When request’s body’s source is null, it means body is created from a ReadableStream object, which means body cannot be recreated and that is why the buffer is needed.

      • Set timingInfo’s final network-response start time to the coarsened shared current time given fetchParams’s cross-origin isolated capability, immediately after the user agent’s HTTP parser receives the first byte of the response (e.g., frame header bytes for HTTP/2 or response status line for HTTP/1.x).

      • Wait until all the headers are transmitted.

      • Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored, except for the purposes of setting timingInfo’s final network-response start time above.

        These kind of responses are eventually followed by a "final" response.

      The exact layering between Fetch and HTTP still needs to be sorted through and therefore response represents both a response and an HTTP response here.

      If request’s header list contains (`Transfer-Encoding`, `chunked`) and response is transferred via HTTP/1.0 or older, then return a network error.

      If the HTTP request results in a TLS client certificate dialog, then:

      1. If request’s window is an environment settings object, make the dialog available in request’s window.

      2. Otherwise, return a network error.

      To transmit request’s body body, run these steps:

      1. If body is null and fetchParams’s process request end-of-body is non-null, then queue a fetch task given fetchParams’s process request end-of-body and fetchParams’s task destination.

      2. Otherwise, if body is non-null:

         1. Let processBodyChunk given bytes be these steps:

            1. If the ongoing fetch is terminated, then abort these steps.

            2. Run this step in parallel: transmit bytes.

            3. If fetchParams’s process request body chunk length is non-null, then run fetchParams’s process request body chunk length given bytes’s length.

         2. Let processEndOfBody be these steps:

            1. If the ongoing fetch is terminated, then abort these steps.

            2. If fetchParams’s process request end-of-body is non-null, then run fetchParams’s process request end-of-body.

         3. Let processBodyError given e be these steps:

            1. If the ongoing fetch is terminated, then abort these steps.

            2. If e is an "AbortError" DOMException, then terminate the ongoing fetch with the aborted flag set.

            3. Otherwise, terminate the ongoing fetch.

         4. Incrementally read request’s body given processBodyChunk, processEndOfBody, processBodyError, and fetchParams’s task destination.

10. If aborted, then:

    1. Let aborted be the termination’s aborted flag.

    2. If connection uses HTTP/2, then transmit an RST_STREAM frame.

    3. If aborted is set, then return an aborted network error.

    4. Return a network error.

11. Let pullAlgorithm be an action that resumes the ongoing fetch if it is suspended.

12. Let cancelAlgorithm be an action that terminates the ongoing fetch with the aborted flag set.

13. Let highWaterMark be a non-negative, non-NaN number, chosen by the user agent.

14. Let sizeAlgorithm be an algorithm that accepts a chunk object and returns a non-negative, non-NaN, non-infinite number, chosen by the user agent.

15. Let stream be a new ReadableStream.

16. Set up stream with pullAlgorithm set to pullAlgorithm, cancelAlgorithm set to cancelAlgorithm, highWaterMark set to highWaterMark, and sizeAlgorithm set to sizeAlgorithm.

17. Run these steps, but abort when the ongoing fetch is terminated:

    1. Set response’s body to a new body whose stream is stream.

    2. If response is not a network error and request’s cache mode is not "no-store", then update response in httpCache for request.

    3. If includeCredentials is true and the user agent is not configured to block cookies for request (see section 7 of [COOKIES]), then run the "set-cookie-string" parsing algorithm (see section 5.2 of [COOKIES]) on the value of each header whose name is a byte-case-insensitive match for `Set-Cookie` in response’s header list, if any, and request’s current URL.

       This is a fingerprinting vector.

18. If aborted, then:

    1. Let aborted be the termination’s aborted flag.

    2. If aborted is set, then set response’s aborted flag.

    3. Return response.

19. Run these steps in parallel:

    1. Run these steps, but abort when the ongoing fetch is terminated:

       1. While true:

          1. If one or more bytes have been transmitted from response’s message body, then:

             1. Let bytes be the transmitted bytes.

             2. Let codings be the result of extracting header list values given `Content-Encoding` and response’s header list.

             3. Increase timingInfo’s encoded body size by bytes’s length.

             4. Set bytes to the result of handling content codings given codings and bytes.

                This makes the `Content-Length` header unreliable to the extent that it was reliable to begin with.

             5. Increase timingInfo’s decoded body size by bytes’s length.

             6. If bytes is failure, then terminate the ongoing fetch.

             7. Enqueue a Uint8Array wrapping an ArrayBuffer containing bytes into stream.

             8. If stream is errored, then terminate the ongoing fetch.

             9. If stream doesn’t need more data ask the user agent to suspend the ongoing fetch.

          2. Otherwise, if the bytes transmission for response’s message body is done normally and stream is readable, then close stream, finalize response for fetchParams and response, and abort these in-parallel steps.

    2. If aborted, then:

       1. Finalize response for fetchParams and response.

       2. Let aborted be the termination’s aborted flag.

       3. If aborted is set, then:

          1. Set response’s aborted flag.

          2. If stream is readable, error stream with an "AbortError" DOMException.

       4. Otherwise, if stream is readable, error stream with a TypeError.

       5. If connection uses HTTP/2, then transmit an RST_STREAM frame.

       6. Otherwise, the user agent should close connection unless it would be bad for performance to do so.

          For instance, the user agent could keep the connection open if it knows there’s only a few bytes of transfer remaining on a reusable connection. In this case it could be worse to close the connection and go through the handshake process again for the next fetch.

    These are run in parallel as at this point it is unclear whether response’s body is relevant (response might be a redirect).

20. Return response. Typically response’s body’s stream is still being enqueued to after returning.