-
-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Set multiple Set-Cookie
headers
#98
Comments
We are planning to merge cookie plugin into Elysia core to resolve the TypeScript error, but we are still deciding on the syntax of it. In the meantime, I added a |
Sweet! Is there an issue for tracking that merge? |
Likely going to be under miyu branch, a candidate for the next release. Currently, I'm implementing tracing and adding unit tests, so it might take some time until the cookie is properly done, I'll let you know once the cookie is ready to be tested. |
This should be fixed with Reactive Cookie in 0.7 #103 Or you can either use
|
Issue
Looking through the source code of
@elysiajs/cookie
, the only way to set multipleSet-Cookie
headers currently is to pass any array tocontext.set.headers["Set-Cookie"]
. An obvious issue is that you have to ignore TS errors, but another issue is that you can override existingSet-Cookie
headers.I'm aware I can just use
@elysiajs/cookie
, but not having a native way to handle it (without TS errors) is an issue IMO. Personally, I'm creating a library API that works with cookies and not having a solution natively sucks.Possible solutions
Context.set.cookie()
This similar to
res.cookie()
in Express. I'm not sure if it's better to accept rawSet-Cookie
header or use a similar syntax to@elysiajs/cookie
where it takes a name, value, and attributes. Either way, it will create a newSet-Cookie
header rather than overriding the existing value.Replace
Context.set
withContext.response
You still can keep the
set
name but I don't thinkset.setHeaders
orset.appendHeaders()
makes sense. Both of these proposal uses a similar API to nativeHeaders
.Also, it makes more sense to get response header values from
context.response
compared tocontext.set
.Update type of
Context.set.headers
toRecord<string, string | string[]>
The same API and implementation but just updated types.
The text was updated successfully, but these errors were encountered: