Tracking issue

[lucacasonato]

This issue links out to all the different parts of the spec that we need to investigate changes in (that we have found so far):

• Allowed request headers
  • Allowing various anti-spoofing headers for outgoing requests #2
  • Allow cookie related headers in outgoing requests #3
  • All other headers should stay forbidden:
    • accept-encoding is related to auto-decompression, see below
    • keep-alive, transfer-encoding, TE are HTTP/1.1 specific headers that are managed by the underlying HTTP stack itself
    • trailers are not supported in fetch yet (see below)
    • upgrade, as there is no upgrade mechanism in fetch (see below)
• Allowed response headers
  • Allow cookie related headers in incoming requests #4
• content-encoding / content-length header sanitization after auto-decompression of the body
  • Automatic decompression should sanitize Content-Encoding and Content-Length headers from the response whatwg/fetch#1729
• Handling of Request and Response properties in init and objects:
  • Handling of properties in Request/Response init dictionaries #5
  • Handling of properties in Request / Response objects #6
• Connection pooling
  • Network partition key is the agent. If a runtime has no notion of agents/clients, then there could be multiple partition keys. All global fetch calls with no explicit agent share a network partition key.
  • Connection pooling: pretty hand-wavey, seems like this is generally only specified for timing. "This is intentionally a little vague"
• Port blocking
  • Need to investigate what different runtimes do
  • Probably needs to be normative optional - there are use cases where you want to permit sending requests to any port
• No request blocking based on mime type
• HTTP extensions
  • origin header should not be set: servers sometimes treat requests with these specially.

There are also some features we have identified as possibly being useful:

• Trailers
• HTTP Upgrade API
• Letting users set content-length for HTTP streams
• API to receive interim responses (100 / 101 status code)
• Allowing async iterables in request / response bodies
• Disabling automatic response body decompression

[andreubotella]

"Main fetch" algorithm:

• Steps 4, 5, 6 are related to CSP and HTTPS requests, don't implement in the server side
• Step 7 also deals with bad ports, see Should we block bad ports? #10
• Steps 8, 9 are about referrer, there's no referrer on the server
• Step 10 is about HTTPs redirection, especially with HSTS. For CLI applications, redirecting to HTTPS if we've previously seen the HSTS headers would be nice, but not as important as for browsers. Also do we want to need the storage?
• Step 12 deals with CORS and response tainting.
  • We might want to just replace it with:
    1. Set request’s response tainting to "basic".
    2. Return the result of running scheme fetch given fetchParams.
  • Basic tainting is what removes the forbidden response headers from a response.
• Step 17: Related to resource and navigation timing; see "fetch response handover". No need to implement.
• Step 18: probably only for browsers
• Step 19 is related to CSP and HTTPS, don't implement in the server side (same as 4,5,6)
• Step 20 shouldn't apply if we've set response tainting to basic
• Step 22 is about integrity metadata, which we said we'll keep in the server side

"Fetch response handover":

• Steps 1, 2 are about resource and navigation timing, exposed as part of performance but not in the minimum common API. Server-side runtimes shouldn't need to implement, but maybe they could anyway.
• Steps 3.3 and 3.4.3 seems to all be about resource and navigation timing as well, no need to implement.

[andreubotella]

"scheme fetch"

• "blob", 3-6 are not relevant to server-side runtimes because they check the blob's origin; same with File API's "obtain a blob object" steps 1-3.
• "file", we will decide when we define a filesystem level for the minimum common API

"determine the environment" is part of figuring out a blob request's origin, not relevant

"HTTP fetch":

• step 3 and step 4.2 are service worker-related. Not sure if there are use cases for service workers in server-side runtimes (cc @jasnell)
• Step 4.1 not relevant (CORS)
• Step 4.5 is origin-related, but TODO
• Step 5 is not relevant (CORS)
• Step 6.2, "manual", step 1: skip (only browsers)
• Step 6.2, "manual", step 2: CORS. Replace with "Set response to a basic filtered response whose internal response is internalResponse"

"HTTP-redirect fetch":

• Step 7, do we want to set it to 20 redirects? Deno and Undici are fine with this, is Workers? (cc @jasnell)
• Steps 9 and 10, skip (CORS)
• Step 13 is origin-related, but needed in server-side runtimes so you don't send authentication data to a different origin. Requires being able to tell whether URLs are cross-origin, but this should already be a thing for any runtimes that implement the URL API.
• (To be continued starting from step 15)

[andreubotella]

"scheme fetch"

• Step 4.5 is origin-related, but TODO

It's related to both origins and resource/navigation timing, so it's not relevant.

[andreubotella]

"HTTP-redirect fetch":

• Steps 15-17 probably not relevant (timing info)
• Step 19 not relevant (we said referer policy shouldn't be implemented)
• Step 21 not relevant (in server-side runtimes, this algorithm is only called with redirect mode "follow")

"HTTP-network-or-cache fetch":

• Step 8.1, traversable for user prompts should be "no-traversable" in server-side runtimes.
• Step 8.3, includeCredentials will be always true (since credentials mode defaults to "same-origin" and can't be overriden, and server-side runtimes will set response tainting to "basic")
• Step 8.4, skip (COEP)
• Step 8.10 is only relevant for runtimes that support fetch in a non-main realm (e.g. node:vm).
• (To be continued starting from step 8.11)

[andreubotella]

"HTTP-network-or-cache fetch":

• Step 8.11-14, skip (referer, origin, fetch metadata)
• (Step 8.20, we should consider improving the language. But we keep that step)
• Step 8.21.1, skip (cookies and)
• Step 8.21.2.2, skip (there should be no authentication entry)
  • For 8.21.2.3, this turns the URL's username and password into an Authorization header
• Deferring steps 8.22-25 when we figure out caching. Our tentative conclusions were:
  • Step 8.22, skip (only applicable for proxies?)
  • Step 8.23, skip (seems to keep caches separated per origin)
• Deferring Steps 10.3-4, 10.5.2 (caching)
• (To be continued starting from step 11)

[andreubotella]

"HTTP-network-or-cache fetch":

• Step 14 skip (traversable for user prompts is "no-traversable"), but we might consider adding some option for user prompts of authentication in the fetch options bag (alongside things like CA certificates).
• Step 15.1 would always return an error, 15.2-5 skip

"HTTP-network fetch":

• Step 3, 7.2, 7.4, 7.5.1, 7.5.4.1 not relevant for runtimes that don't have PerformanceObserver (timing info)
• Step 7.3 disallows stream request bodies for HTTP/1.x, even though they apparently can be chunked. Should we support this in server-side runtimes? See Request body streams should use chunked encoding whatwg/fetch#966, https://developer.chrome.com/docs/capabilities/web-apis/fetch-streaming-requests#streaming_request_bodies
• Step 7.5.(certificate dialog).1, skip ("no-traversable") unless we add an option for prompts.
• Step 15, skip (cookies)
• Step 16.2.1.2, we probably want to use the same realm as the fetch method. It's odd that it's implementation-defined in the spec. Can we change the spec?

(To be continued with "CORS-preflight fetch")

[andreubotella]

Sections 4.7 (CORS-preflight fetch), 4.8 (CORS-preflight cache), 4.9 (CORS check) and 4.10 (TAO check) are not relevant because of origins. (As for TAO, see #1 (comment))