Improved set header and set cookie experience

[wesleytodd]

In a recent thread on the cookie module it became clear that the core setHeader api is not very optimal for some use cases. The main issue is that it does not support progressively adding multiple headers of the same name. The set-cookie header is the most clear example of this because applications often set multiple cookies in one response.

I think there is opportunity to pull some of the behaviors of cookie and cookies into the setHeader method. If we were able to "append header" it would help with the progressive addition of set-cookie headers.

But I wanted to also field the idea of moving a full cookie parsing implementation into node. Is there a clear reason why this is a bad idea? I recognize that small core is a feature, but the ease of a using doing res.setCookie('token', '...') seems to be pretty compelling IMO.

[arei]

I actually think this is a great idea, but let me take a slightly contrary position for a second...

What about the other headers that have encoded information in them that is somewhat hard to parse? I'm particularly thinking of content-type and getting the encoding out of it, but I am sure there are others. Are we signing up to end up creating parsing rules for these as well?

I truly love the idea of adding functionality that makes life easier, but where do we draw the line around that.

[wesleytodd]

I'm particularly thinking of content-type and getting the encoding out of it, but I am sure there are others.

I think each domain will have pros/cons for having a core implementation and to keep the conversations clear I don't want to take on too much at once. We can make individual decisions on what makes sense.

[wesleytodd]

Next steps on this, as discussed on the meeting, are to look at what an improved experience around the entire header handling in http looks like. @mcollina referenced many issues with the current api and how in Fastify the only reasonable way was to not use the setHeader api (links to come). We can discuss what gaps there are and how we can get an api which is better for use by frameworks in general.

[wesleytodd]

Update on next steps: We would like help building a prototype of an improved headers api based on this spec: https://developer.mozilla.org/en-US/docs/Web/API/Headers

The goal will be to have a prototype library frameworks can use in the mean time, to help push the conversation forward with core.

[delvedor]

@wesleytodd I already have a small prototype, I could make it public and invite you all to collaborate :)

[Ethan-Arrowood]

Would love to collaborate @delvedor

[antsmartian]

@delvedor It would be great, if you can share the repo here.

[delvedor]

Here's the repository :)
I just pushed the code, as you can as is still a very small prototype. I started working on it a few weeks ago while reading the spec, which you can find here.

If you want, I can transfer the repo into the Node.js GitHub org :)

https://github.com/delvedor/whatwg-headers

[wesleytodd]

This effort will be wrapped up in #55. Going to close this up for now.