You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't a bug in this project per se but something I thought I should bring to your attention.
Setting more than one header of the same name in a Lambda response is very difficult to do reliably. Here is the current state of affairs:
APIGateway: Does not support multiValueHeaders in payload format "2.0", only in "1.0"
Elastic Load Balancer: Only supports multiValueHeaders if you explicitly opt-in to it with lambda.multi_value_headers.enabled. Furthermore it reverses the header order which is devastating for headers like Set-Cookie
Lambda Function URL: Does not support multiValueHeaders at all
So without metadata on the deployment and routing of the Lambda function this response is inherently unsafe. I'm honestly bewildered by how wrong the AWS team has consistently botched this 26 year old protocol.
I'm going to further test this solution to see if it maintains the order of the headers and will report back.
Edit: It's bad:
APIGateway Payload 1.0: Returns only the first header
APIGateway Payload 2.0: Returns only the last header
Elastic Load Balancer: Returns headers of each case, order still reversed. lambda.multi_value_headers.enabled must be false or headers is ignored entirely.
Lambda URL: Returns the last header
There is a cookies response property which is supported by APIGateway payloads 2.0, and Lambda URL. Unsupported by APIGateway payload 1.0 & Elastic Load Balancer.
Based on this reverse engineering I think that Lambda URL is using APIGateway on the backend with payload format 2.0, though I can't find this documented anywhere.
I put together a CloudFormation stack to demonstrate the issue in AWS's services: execute.sh
This isn't a bug in this project per se but something I thought I should bring to your attention.
Setting more than one header of the same name in a Lambda response is very difficult to do reliably. Here is the current state of affairs:
multiValueHeaders
in payload format "2.0", only in "1.0"multiValueHeaders
if you explicitly opt-in to it withlambda.multi_value_headers.enabled
. Furthermore it reverses the header order which is devastating for headers likeSet-Cookie
multiValueHeaders
at allSo without metadata on the deployment and routing of the Lambda function this response is inherently unsafe. I'm honestly bewildered by how wrong the AWS team has consistently botched this 26 year old protocol.
I found this idea on StackOverflow which is honestly a brilliant workaround. You can toggle the casing in the returned headers in order to reliable send multiple headers:
https://stackoverflow.com/questions/66284664/multiple-set-cookie-headers-ignored-by-api-gateway-in-combination-with-lambda-in#answer-66317294
I'm going to further test this solution to see if it maintains the order of the headers and will report back.
Edit: It's bad:
lambda.multi_value_headers.enabled
must be false orheaders
is ignored entirely.There is a
cookies
response property which is supported by APIGateway payloads 2.0, and Lambda URL. Unsupported by APIGateway payload 1.0 & Elastic Load Balancer.Based on this reverse engineering I think that Lambda URL is using APIGateway on the backend with payload format 2.0, though I can't find this documented anywhere.
I put together a CloudFormation stack to demonstrate the issue in AWS's services:
execute.sh
Stack.yaml
The text was updated successfully, but these errors were encountered: