I've been trying to set multiple Set-Cookie headers. As JS does not allow duplicate keys, the officially supported way to do this on APIG is via the multiValueHeaders property in the handler response. Using Vandium 4.10 these do not set properly. The response when inspected contains no Set-Cookies at all if I use mVH. Interestingly I get different results depending on whether I'm deploying via sls or running locally via sls offline - perhaps I should bring that up with them.
Using Serverless Offline, setting Set-Cookie to an array works, as responses bear multiple Set-Cookie headers. This does not work when deployed via sls deploy. I suspect it's an APIG response formatting discrepancy between the mock and the OG.
Rewriting the handler to not use Vandium, instead with the traditional Serverless handler signature, sets multiValueHeaders correctly ( incidentally disabling support for headers to be arrays ).
Solution Starting Point:
The problem lies in what APIG expects the response to look like. It doesn't appear from the Vandium code that anything out of the ordinary is occurring, or should occur, for mVH values, or array values for regular headers. Perhaps Vandium is not serializing mVH correctly.
Description:
I've been trying to set multiple
Set-Cookie
headers. As JS does not allow duplicate keys, the officially supported way to do this on APIG is via themultiValueHeaders
property in the handler response. UsingVandium 4.10
these do not set properly. The response when inspected contains noSet-Cookies
at all if I usemVH
. Interestingly I get different results depending on whether I'm deploying viasls
or running locally viasls offline
- perhaps I should bring that up with them.Using Serverless Offline, setting
Set-Cookie
to an array works, as responses bear multipleSet-Cookie
headers. This does not work when deployed viasls deploy
. I suspect it's an APIG response formatting discrepancy between the mock and the OG.Rewriting the handler to not use Vandium, instead with the traditional Serverless handler signature, sets multiValueHeaders correctly ( incidentally disabling support for headers to be arrays ).
Solution Starting Point:
The problem lies in what APIG expects the response to look like. It doesn't appear from the Vandium code that anything out of the ordinary is occurring, or should occur, for
mVH
values, or array values for regular headers. Perhaps Vandium is not serializingmVH
correctly.