lambdaurl Wrap is not proxying `LambdaFunctionURLRequest.Cookies`

[nguyengg]

Is your feature request related to a problem? Please describe.
The Wrap function from https://github.com/aws/aws-lambda-go/blob/main/lambdaurl/http_handler.go#L105 creates an http.Request from an events.LambdaFunctionURLRequest. I don't see any references to proxying the original request's cookies similar to what aws-lambda-go-api-proxy does:

	for _, cookie := range req.Cookies {
		httpRequest.Header.Add("Cookie", cookie)
	}

This is a deal-breaker for me because my stream handlers rely on cookies

Describe the solution you'd like
Copy and paste that code block (I'll do this with a PR after creating this issue).

Describe alternatives you've considered
I don't think this module would like to take a dependency on aws-lambda-go-api-proxy so copying and pasting may be best.

Additional context
None.

[nguyengg]

From what I can tell in https://github.com/aws/aws-lambda-go/blob/main/lambdaurl/testdata/function-url-request-with-headers-and-cookies-and-text-body.json and https://github.com/aws/aws-lambda-go/blob/main/lambdaurl/http_handler_test.go#L51, looks like only cookies in the LambdaFunctionURLRequest.Headers["cookie"] are proxied to the resulting http.Request. This will break use cases where users rely on LambdaFunctionURLRequest.Cookies instead.

Will AWS Lambda Function URL handlers always receive identical .Cookies and .Headers["cookie"] values?

[bmoffatt]

What's the scenario where cookies aren't making it into the handler? I wasn't able to reproduce this with a Function URL. For me, both request.cookies and request.headers.cookie appear to be populated when a Cookie: header is supplied by the client.

[nguyengg]

What's the scenario where cookies aren't making it into the handler?

I believe it was from manual integration tests invoking the Lambda handler that was only specifying cookies as top-level attributes in payload but not inside the headers attribute. This was from Oct 2025 and I was migrating and benchmarking webapp and API handlers to STREAMING response. Since I successfully migrated the NodeJS webapp handlers but not the API handlers, that was good enough for me since the payoff from the webapp handler was more important.

In retrospect, fixing the test payloads would have been a sufficient workaround.