lambda_http 0.11.3 breaks response headers

[jantb]

I'm getting no response headers when using the latest version of lambda http,

I am using this config in cargo.toml
lambda_http = { version = "=0.11.3",default-features = false, features = ["apigw_http"] }

0.11.1 does not have this issue:

Here is how I set the response in the handler

   Ok(Response::builder()
        .status(200)
        .header("content-type", "text/html")
        .body("something".into())
        .map_err(Box::new)?)

curl -v shows this as the headers with version 0.11.1

< HTTP/2 200 
< date: Wed, 15 May 2024 13:48:35 GMT
< content-type: text/html
< content-length: 553
< apigw-requestid: ...

and for 0.11.3:

< HTTP/2 200 
< date: Wed, 15 May 2024 13:52:58 GMT
< content-type: text/plain; charset=utf-8
< content-length: 553
< apigw-requestid: ...

This seems related to this commit
fc49dd5
which is the only one in 0.11.3

[shortjared]

This also broke us, it broke CORS Allow-Origin headers in our case.

[calavera]

Ugh. I'm very sorry about that. I've yanked that version from crates.io. It looks like this is not consistent in all the integrations: #852. We'll investigate further.

[calavera]

@jantb how did you create your APIGW? I wonder if there are some settings that we're missing, and affect how headers are returned

[calavera]

@shortjared which service do you integrate with, APIGW? which kind? If you have any configuration that you can share, it'd be very helpful.

[jantb]

Here is the setup of the http APIGW:

val httpApi =
            HttpApi(
                this, "Api", HttpApiProps.builder()
                    .apiName("api")
                    .corsPreflight(
                        CorsPreflightOptions.builder().allowOrigins(
                            listOf(
                                "xxx",
                                "xxx",
                                "http://localhost:8080",
                            )
                        ).allowMethods(CorsHttpMethod.entries)
                            .build()
                    )
                    .build()
            )

and the functions are added with:

  AddRoutesOptions.builder().path(path).methods(listOf(method))
            .integration(
                HttpLambdaIntegration(
                    "$functionName-integration",
                    function
                )
            ).build()     

Cloudformation:

{"Api": {
   "Type": "AWS::ApiGatewayV2::Api",
   "Properties": {
    "CorsConfiguration": {
     "AllowMethods": [
      "*",
      "DELETE",
      "GET",
      "HEAD",
      "OPTIONS",
      "PATCH",
      "POST",
      "PUT"
     ],
     "AllowOrigins": [
      "",
      "",
      "http://localhost:8080"
     ]
    },
    "Name": "api",
    "ProtocolType": "HTTP"
   },
   "Metadata": {
    "aws:cdk:path": "xxx/Api/Resource"
   }
  }
  }

{
  "ApiGETservehtmlintegration": {
   "Type": "AWS::ApiGatewayV2::Integration",
   "Properties": {
    "ApiId": {
     "Ref": "ApiF"
    },
    "IntegrationType": "AWS_PROXY",
    "IntegrationUri": {
     "Fn::GetAtt": [
      "servehtml",
      "Arn"
     ]
    },
    "PayloadFormatVersion": "2.0"
   },
   "Metadata": {
    "aws:cdk:path": "xxxx/Api/GET--/serve-html-integration/Resource"
   }
  }}
            

[fluxth]

Also reporting that lambda function URL regression (previously in #871) is still present in 0.11.3.

Lambda function URLs use API gateway v2 format:

The request and response event formats follow the same schema as the Amazon API Gateway payload format version 2.0.

https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html#urls-payloads

---

Note that in #852, the author references a pull request from aws-lambda-go-api-proxy repo from 2020. That was before the code base was refactored to split the types for API gateway v1/v2 & ALB integrations.

• https://github.com/awslabs/aws-lambda-go-api-proxy/blob/3f6c8160ae0c22b0bd05b2e3a9122736f035c74b/core/response.go#L117
• https://github.com/awslabs/aws-lambda-go-api-proxy/blob/3f6c8160ae0c22b0bd05b2e3a9122736f035c74b/core/responseALB.go#L108
• https://github.com/awslabs/aws-lambda-go-api-proxy/blob/3f6c8160ae0c22b0bd05b2e3a9122736f035c74b/core/responsev2.go#L117

They currently handle header keys differently based on integration types there on master.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.