[Meeting] 2022-12-01 08:00am Pacific time

[jasnell]

Agenda items:

• Updates on current initiatives
  • fetch spec
  • runtime keys
  • common minimum api
  • async context
• Socket APIs (jasnell) - Cloudflare is working on a Socket API that is based on ReadableStream/WritableStream. We've noticed some inconsistencies in the way things are implemented across Node.js, Deno, etc.
• Specifier namespaces (jasnell) - Node.js recently introduced the node:... specifier prefix for built-in modules, Deno just introduced use of the npm:... specifier prefix for npm modules. In Workers, we are starting on Node.js-compatibility using the node:... prefix. Should we standardize on these prefixes? Would the runtime keys help here?

[Ethan-Arrowood]

"Node.js Spec"

Its been discussed previously (before WinterCG was even founded), and now it is making rounds again. Would like to hear people's thoughts on it especially motivations and how it would fit into the WinterCG world (we already have minimum common api proposal).

[ytxmobile98]

I would like to continue a discussion regarding the fetch API.

In fetch we may have a { redirect: 'manual' } option. When this option is set and a redirect is detected, the agent will not follow the actual URL, but will rather stop and let the developer specify how it behaves differently.

In WHATWG spec it says that it needs to return an opaque-redirect filtered response where status code is 0, status text is empty string, and type is opaqueredirect. In addition, in major browser implementations, the URL in the response is the URL that the fetch initially requested, not the actual URL it should follow.

However in Node.js the behavior is different: the status code is 3xx (meaning redirect), and the status text is the HTTP message that matches the redirect code. The type is default.

I also checked Deno and observed similar behavior.

So I would like to have a discussion regarding the details of manual redirects in fetch as we are gradually establishing the WinterCG standard.

I am raising this topic because I am working with service workers at my company, and in those scenarios people may be interested in what the exact redirected URLs are and use them in the workers accordingly. In the browser environment it makes sense not to have everything transparent when it comes to handling redirects, for better security protection. However in the worker environment such protection may make much less sense; instead, service workers may do a variety of different things to handle the redirect.

Prior discussions:

• Cannot get next URL for redirect="manual" whatwg/fetch#763
• Fetch: Allow manual redirect handling nodejs/undici#1193
• lib: add fetch nodejs/node#41749
• fix(op_crates/fetch): redirect: "manual" fetch should return type: "default" response denoland/deno#8353
• fetch(..., {redirect: 'manual'}) does not work propertly denoland/deno#4389

[dom96]

For reference, here is what I presented today: https://gist.github.com/dom96/11fa8f568c9ae99a77784d9699f05a24

[Ethan-Arrowood]

To Do:

• Create issue in that captures this comment: [Meeting] 2022-12-01 08:00am Pacific time #41 (comment)
• Comment desired answer

Add a new property to request options that allows wintercg/fetch to return the relevant information. Something like fetch('//:url', { redirect: 'manual', foobar: true }).

• Adjust our spec to reflect change

[jasnell]

Meeting recording link: https://us06web.zoom.us/rec/share/l2hIkjKjrEpoiW99BFpkOcrPgk8h7waa4ND5ECbPfZ_BpNHciS5e2NTkRJkAdDod.75-aHKWiklEAkyW0
Passcode: c.#NT97C