Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/WinterTC55/fetch/issues/6 below:

Request/Response browser differences · Issue #6 · WinterTC55/fetch · GitHub

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

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

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

1. response.type **

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

• 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

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

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

exoticknight and jdalrymple

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4