Discrepancy in adding headers after v 0.8.1?

[intothelonezone]

Hi lambda_http folks. Wanted to ask this discussion group before digging deeper and (potentially) opening an issue.

1. I downloaded the http-cors example project
2. I run the function using cargo lambda watch / invoke using lambda_http v 0.13.0
3. Headers I add to the response only show in the multiValueHeaders property. The headers property is empty.
4. When switching to version 0.8.1 (or lower), the headers property gets filled as expected in the response object.

Here's a short video demonstrating: https://youtu.be/0tFobUcEhbk

Let me know if I'm missing anything or if you'd like to see more. I see there is some code in lambda_http that handles headers depending on ApiGatewayV1 or V2. I see there is code handling V1 with proxies, but I'm unsure if this would affect what I'm seeing currently (or is even relevant).

Am new to Rust so thanks for your patience.

[intothelonezone]

Amendment 1

My suspicion is that this commit might have something to do with it. But this was submitted after lambda-http v0.11.0, and the empty headers begins with this version, 0.11.0.

This commit seems to make headers empty intentionally because of some problem with API Gateway. But I'm unsure why making headers empty was the solution instead of making multiValueHeaders empty. Did the author intend for developers to populate headers another way?

[calavera]

That was an intentional change. See the PR description:

The issue here is that the API Gateway does not properly merge single-value headers and multi-value returned by the Lambda and instead returns both to the client. Since this library just puts the same headers into both, this means that every header is returned twice (more or less, in the case of actual multi-value headers, only the first element is duplicated). In the case of CORS, this is fatal, as browsers generally reject duplicate CORS headers.

[intothelonezone]

Thanks David! I really appreciate the reply and context. In this case, how should one properly fill the headers property for the response? The problem I have is that browsers look for the Access-Control-Allow-Origin header, but I seem to have no way to add a header besides the multiValueHeaders property, which the browser doesn't look for.

Thanks again for your help.

[calavera]

How are you serving http requests from Lambda? Are you using APIGW, Lambda Function URLs, ALB, other? APIGW, Lambda Function URLs and ALB will set the headers or multiValueHeaders fields for you in the response automatically, you don't have to do anything. If you're sending invocations to Lambda from other service, you'll have to make the translation manually.

[intothelonezone]

I'm using API Gateway with the proxy integration for a Lambda function.

Using Javascript/Node, I made the header object myself when using proxy integration, including CORS-related headers. I then included the header object in the response from the Lambda handler.

(And I'm unable to set any headers in API Gateway's response because of the Lambda proxy.)

Thanks again!

[calavera]

That should work out of the box. You don't have to worry about whether the values are in headers or multiValueHeaders when you use APIGW. What you're seeing in your video is the raw output from Lambda. APIGW will take that output and generate the response correctly for you.

[intothelonezone]

You're right! I connected an API Gateway endpoint to both a sample lambda_http function and one of my own and now the headers are coming through as expected.

I'm not sure how I missed it. I had to deal with a lot of CORS-related issues so I must've overlooked the API Gateway integration possibilities. But I did not know that APIG automatically manages headers for a proxy integration. So that is an important fact I learned. Thanks a million for your help David. I truly appreciate you taking the time to review this with me. I hope to learn enough about this repo to return the favor someday.