Repository navigation
Improved set header and set cookie experience #32
Description
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.
Activity
[-]Improved set cookie api[/-][+]Improved set header and set cookie experience[/+]arei commentedon Feb 20, 2020
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-typeand 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 commentedon Feb 20, 2020
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 commentedon Apr 30, 2020
Next steps on this, as discussed on the meeting, are to look at what an improved experience around the entire header handling in
httplooks like. @mcollina referenced many issues with the current api and how in Fastify the only reasonable way was to not use thesetHeaderapi (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 commentedon May 28, 2020
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 commentedon May 28, 2020
@wesleytodd I already have a small prototype, I could make it public and invite you all to collaborate :)
Ethan-Arrowood commentedon May 29, 2020
Would love to collaborate @delvedor
antsmartian commentedon May 29, 2020
@delvedor It would be great, if you can share the repo here.
delvedor commentedon May 29, 2020
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 commentedon Jul 23, 2020
This effort will be wrapped up in #55. Going to close this up for now.