Re: [whatwg/fetch] Use case for Headers getAll (#973)

@domenic I did not phrase that very elegantly. What I meant was that there is no value for the web if this change is looked at in total isolation, pretending that the `Headers` class is implemented and used only in the browser (ignoring the existence of server side JS runtimes that have the `Headers` class). This is obviously not the case though. `Headers` are used in browsers, Deno, Cloudflare Workers, Node.js and various other server side runtimes. 

It is correct that the primary users of this specific feature are going to be users of server side JS runtimes. Developers developing _exclusively_ for the web are likely not going to use this. It is critically important however that the API behaves the same in server side runtimes, and browsers. Otherwise packages written for both will need to branch behaviour on the runtime, which is not great.

`[...new Headers([["set-cookie": "foo"], ["set-cookie": "bar"]])]` should return the same result across browsers and server side runtimes. Not doing so is confusing, and will fragment the ecosystem.

That is the real value for browsers: keeping the API consistent between runtimes, and to avoid user confusion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/973#issuecomment-961048253