Giters

awslabs / aws-lambda-rust-runtime

A Rust runtime for AWS Lambda

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

lambda_http 0.11.3 breaks response headers

jantb opened this issue · comments

commented

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

commented

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

commented

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.

commented

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

commented

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

commented

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"
   }
  }}
commented

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.

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

commented

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.