Skip to content

Handling of properties in Request/Response init dictionaries #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lucacasonato opened this issue Feb 20, 2025 · 0 comments
Open

Comments

@lucacasonato
Copy link
Member

That covers RequestInit and ResponseInit:

  • RequestInit.method: ✅

  • RequestInit.headers: ✅

  • RequestInit.body: ✅ (Node.js diverges because it supports AsyncIterables here)

  • RequestInit.signal: ✅

  • RequestInit.redirect:

    • follow: ✅
    • error: ✅
    • manual: ✅, but divergence because the returned response is not opaque. On the browser it is opaque because of Atomic HTTP redirect handling - this security feature is not needed on servers.
  • RequestInit.integrity: 🟠

    • Must be verified, and if the supported integrity string is not supported, must throw.
    • At minimum must support undefined and "".
    • We think this may be useful on the server, but it should be up to the host to determine to what extent they implement this.
  • RequestInit.duplex: ✅

    • We should spec what duplex: full means
    • We should try to get duplex: full to be the default in browsers
    • We should start enforcing duplex: "half" if you want half duplex in server environments
  • RequestInit.cache: 🟠

    • Verify the property is valid
    • The default on server runtimes is no-store or no-cache, not default
    • Runtimes must send the correct cache control header corresponding to the specified option
    • Runtimes do not actually have to cache responses in a client side cache
    • Verify if the spec allows implementations to "downgrade" to lower cache level (like no-store) even if a higher value is specified, for example in Incognito windows. If so, we do not need to throw on unsupported valid values.
    • Figure out how default and Cloudflare's default behaviour differ - do we need another value to specify that behaviour?
  • RequestInit.priority: 🟠

    • Either implement as specced, or completely ignore it
  • RequestInit.referrer: ❌ ignore completely (do not get off init)

    • Servers don't have an active site/origin so there is no referrer
  • RequestInit.referrerPolicy: ❌ ignore completely

    • If you don't have a referrer, you don't need a policy for them
  • RequestInit.mode: ❌ silently ignore

    • CORS is not relevant on the server
  • RequestInit.credentials: ❌ silently ignore

    • CORS is not relevant on the server
    • Check that credentials: omit does not remove explicitly set auth headers - if so, reconsider
  • RequestInit.keepalive: ❌ silently ignore

    • Related to tab lifetime, not relevant to server runtimes
  • RequestInit.window: ❌ silently ignore

    • no windows
  • ResponseInit.status: ✅

  • ResponseInit.statusText: ✅

  • ResponseInit.headers: ✅

✅ = mandatory
🟠 = sometimes
❌ = ignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant