Request/Response browser differences
KhafraDev opened this issue · comments
Currently, both the Request
and Response
classes contain a bunch of properties that likely have no effect server-side.
Request:
request.destination
request.referrer
request.referrerPolicy
request.mode
*request.cache
"...indicating how the request will interact with the browser’s cache when fetching"request.integrity
"A cryptographic hash of the resource to be fetched by request."request.isReloadNavigation
request.isHistoryNavigation
RequestInit
(options that are passed to the Request
constructor)
RequestInit.referrer
: "A string whose value is a same-origin URL"RequestInit.referrerPolicy
: "A referrer policy to set request’s referrerPolicy."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"."RequestInit.credentials
: seerequest.credentials
*RequestInit.cache
: seerequest.cache
RequestInit.integrity
: seerequest.integrity
RequestInit.window
: "Can only be null. Used to disassociate request from any Window."
Response
* 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:
- Choose default values to return for useless flags (for example, node.js' Request class will always return
false
forrequest.isHistoryNavigation
). Default flags would also be needed forRequestInit
as the spec heavily defines fetch's behavior from certain flags being set. - 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.
- 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
Additional behaviour to align is whether to ignore or throw on unsupported options.
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
pinging @ronag and @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.
undici supports integrity
now.