Request/Response browser differences

[KhafraDev]

Currently, both the Request and Response classes contain a bunch of properties that likely have no effect server-side.

Request:

1. request.destination
2. request.referrer
3. request.referrerPolicy
4. request.mode *
5. request.cache "...indicating how the request will interact with the browser’s cache when fetching"
6. request.integrity "A cryptographic hash of the resource to be fetched by request."
7. request.isReloadNavigation
8. request.isHistoryNavigation

RequestInit

(options that are passed to the Request constructor)

1. RequestInit.referrer: "A string whose value is a same-origin URL"
2. RequestInit.referrerPolicy: "A referrer policy to set request’s referrerPolicy."
3. RequestInit.mode: "A string to indicate whether the request will use CORS, or will be restricted to same-origin URLs. Sets request’s mode. If input is a string, it defaults to "cors"."
4. RequestInit.credentials: see request.credentials *
5. RequestInit.cache: see request.cache
6. RequestInit.integrity: see request.integrity
7. RequestInit.window: "Can only be null. Used to disassociate request from any Window."

Response

1. response.type **

* omit and include may be useful for developers, however same-origin is not.
** cors should be omitted from this type.

Implementations:

• node.js: implements "everything" according to the spec (even things that aren't relevant to a server environment).
• Deno: https://deno.land/manual/runtime/web_platform_apis#fetch-api
• node-fetch: https://github.com/node-fetch/node-fetch#class-request
• Cloudflare workers: https://developers.cloudflare.com/workers//runtime-apis/request#requestinit https://developers.cloudflare.com/workers//runtime-apis/request#properties

Aligning Behavior

As you can see, each environment is different in supported properties which can cause cross-platform confusion. It also makes everything more confusing considering that these platforms typically leave in unsupported properties in their typings, but do not document which types are ignored (unless you look for it on google).

Potential Solutions:

1. Choose default values to return for useless flags (for example, node.js' Request class will always return false for request.isHistoryNavigation). Default flags would also be needed for RequestInit as the spec heavily defines fetch's behavior from certain flags being set.
2. Fork the fetch spec and remove mentions of these flags, along with conditions that would no longer be possible with said flags being removed. This would be a lot of work.
3. Create a new document that would supersede certain steps/behaviors in the fetch spec. For example:

<-- Original fetch spec -->

# some title
1. If request's mode is "cors" then:
   ...
2. Perform scheme fetch.
3. If request's `referrer` is not this's current settings origin url then:
   1. Abort this request.
   2. Return a network error.
// and so on

<-- Server environment spec -->

# some title
1. Ignore step 1
3. Ignore step 3
// and so on

[panva]

Additional behaviour to align is whether to ignore or throw on unsupported options.

[lucacasonato]

My preference is to not implement any of these fields, not have the getters for them present on the prototype, and as such not explicitly raise any errors about these fields. We briefly had previous behaviour in the past, but usage showed that users prefer the fields to not be present at all. Please take a look at denoland/deno#10286

[KhafraDev]

pinging @ronag and @jimmywarting

[jimmywarting]

• node-fetch has a long standing issue about including credentials or not. if a person would add credentials=omit then it would not send credentials such as Authentication and/or Cookies if they would be included in the headers, but nothing as such has been implemented. same-site could perhaps have extra value in things such as when a page redirects to an 3th party domain maybe. the default from some redirect is to forward all headers.

• integrity could certainly be added on the backend as well too ensure that the response is what it's... just need to compare the response when reading it and reject the request/response when it dose not match. i could also see it as potentially useful but node-fetch don't currently have it either.

• adding cors don't really have any valuable meaning i think? it's on a server after all and don't have a concept of a origin?

• referrerPolicy... ping @tekwiz who implemented something to node-fetch (have something to do with redirects)

• cache would be a nice addition if we ever where to implement a default cache feature. it could be pretty cool and possible save a lot of bandwidth. maybe would be even nicer to have now that nodejs also supports http-import.

I have wonder what i would maybe try to build next now that fetch is built right in to NodeJS and i have had my ideas on a some CacheStorage but for the server side.

[KhafraDev]

undici supports integrity now.