Return first value in the internal array when calling Response.get() or something?

[BobbyWibowo]

This is related to my previous discussion about Response's .set()/.header() actually only keeping last value in #88

It appears said behavior is because in ExpressJS, every calls to .set()/.header() will directly call http.ServerResponse.setHeader(), which will always overwrite existing headers with the same names
https://github.com/expressjs/express/blob/4.18.1/lib/response.js#L776-L801
https://nodejs.org/docs/latest-v16.x/api/http.html#responsesetheadername-value

So when using http.ServerResponse.setHeader() directly with multiple Set-Cookie headers, you're supposed to set the value into an array of strings, to instruct http to later split them into multiple Set-Cookie headers for network transmission (meaning before the Response is finalized, their values will still be kept as-is)
That applies to any header names if their values are arrays, not just Set-Cookie

And thus ExpressJS's .cookie() will instead call an internal .append(), that merely gets previously set value/array to concat into, before then re-applying the new array into the header name
https://github.com/expressjs/express/blob/4.18.1/lib/response.js#L854-L887
https://github.com/expressjs/express/blob/4.18.1/lib/response.js#L744-L756

As for ExpressJS's .get(), it is merely a direct call to http.ServerResponse.getHeader()
https://github.com/expressjs/express/blob/4.18.1/lib/response.js#L811-L813
And since headers values are being kept as-is before being finalized, during normal non-cookies use case, you'd expect them to return the string values as-is (or number, etc., or even array of something, depending on how you previously set them)

I'm not sure what's the best way to align the behavior of current hyper-express' codes aside from just refactoring the headers system,
thus my lazy idea in the discussion title

[kartikk221]

I see, so I have a plan for a major overhaul of the compatibility methods. Essentially my plan is to first support all compatibility methods/properties from Node's native http.IncomingMessage and http.ServerResponse classes. Then support as many ExpressJS properties/methods on top of these methods. This way there will be consistency in behavior across all Node.js HTTP based webservers.

I've been focusing my last few updates on performance and implementing features from uWebsockets.js but compatibility is my next roadmap target.

[BobbyWibowo]

Got it, I will look forward to future updates

For the time being I just have a simple middleware aliasing the functions into a behavior that I expect
Sufficient for me as a temporary workaround