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

> I agree that it's not desirable to have Request or Response instances that can contain Set-Cookie headers in their Header objects.

But only on the web! In server side environments like Deno and Cloudflare Workers, `Response` objects are used to represent outgoing HTTP responses from the server to the client. These must be able to contain `set-cookie` headers. On the web `Response` objects containing a `set-cookie` headers can already **not** be created, because `Response`'s headers use a `"response"` header guard, which forbids `"set-cookie"` headers. Both Deno and CFW work around this by not considering `set-cookie` a forbidden response-header name.

For `Request` objects I have no interest or opinion on `set-cookie` headers being allowed. They are basically useless, and I don't think anyone would be hurt if the header were to be blocked for requests.

I would be strictly opposed to any changes to the header representation in the spec (even just in `Response` objects) that would that would cause `set-cookie` headers to be unsupportable by otherwise conformant implementations.

> It is unclear to me how valuable an addition this is to the web platform.

There is no inherent value to the web browsers specifically: `set-cookie` headers on responses are never exposed in the web platform, so users can not manually use these. The value lies in broader ecosystem compatibility and uniformity. Web browsers are just one of the implementors of the fetch spec: other JS runtimes use this API for HTTP fetches too (e.g. Deno, Cloudflare Workers, Node.js when using `node-fetch`). If the API that all of these runtimes use is standardised and uniform, it becomes much easier to write code that is portable across runtimes. Reading and setting `set-cookie` headers is a critical feature for server side HTTP implementations.

-- 
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-960840381