502 Bad Gateway error because Headers field is nil

kdeloach commented 3 years ago

I get 502 Bad Gateway response from AWS LB using the exact source code from the README with the latest release v0.8.1.

This is due to a recent change in #73 which results in Headers being set to nil on the proxy response. You can work around this by adding Headers to the proxied response.

Lambda output and HTTP response using the code from the README:

{
  "statusCode": 200,
  "headers": null,
  "multiValueHeaders": {
    "Content-Type": [
      "application/json; charset=utf-8"
    ]
  },
  "body": "{\"message\":\"pong\"}"
}

$ curl http://<removed>.elb.amazonaws.com/ping
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

My workaround:

func Handler(ctx context.Context, req events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    // If no name is provided in the HTTP request body, throw an error
    resp, err := ginLambda.ProxyWithContext(ctx, req)
    headers := make(map[string]string)
    headers["Content-Type"] = "application/json"
    resp.Headers = headers
    return resp, err
}

Lambda output and HTTP response with this workaround:

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json"
  },
  "multiValueHeaders": {
    "Content-Type": [
      "application/json; charset=utf-8"
    ]
  },
  "body": "{\"message\":\"pong\"}"
}

$ curl -i http://<removed>.elb.amazonaws.com/ping
HTTP/1.1 200 OK
Server: awselb/2.0
Date: Thu, 08 Oct 2020 18:59:03 GMT
Content-Type: application/json
Content-Length: 18
Connection: keep-alive

{"message":"pong"}

NotSoSuper commented 2 years ago

Can confirm this issue with Application Load Balancers too, reverting #73 results in a properly working HTTP response.

Only noticed this issue after updating from v0.8.0 to v0.12.0

tgilino commented 2 years ago

Ran into this issue myself with only Lambda functions (not using HTTP API or ALB), and additionally HTTP API Payload Format 2.0 has removed multi-value headers and just uses headers. I don't think there should be a non-pointer field that is not initialized.

Is there a plan to fix?

mcku commented 1 year ago

I think I've faced this issue and realized that the Headers field always nil. (https://github.com/awslabs/aws-lambda-go-api-proxy/blob/master/core/response.go#L108)

In my case, API Gateway failed with internal error until headers was populated with content type at least.

louism517 commented 1 year ago

Are there any plans to fix this? Its a bit annoying to have to craft some dummy headers just to make it work.

kubamarchwicki commented 1 year ago

The fix is in the AWS target group. By default, ALB requires a content-type header and by default it ignores multi-value headers (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html#enable-multi-value-headers).

Even though the aws-lambda-go-api-proxy sets the default headers, they are ignored by the ALB. Had the same issues and setting the multi-value header flag to true resolved issues for me

iguoyr commented 3 months ago

The fix is in the AWS target group. By default, ALB requires a content-type header and by default it ignores multi-value headers (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html#enable-multi-value-headers).

Even though the aws-lambda-go-api-proxy sets the default headers, they are ignored by the ALB. Had the same issues and setting the multi-value header flag to true resolved issues for me

Works for me! tks!

awslabs / aws-lambda-go-api-proxy

502 Bad Gateway error because Headers field is nil #79