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

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