ApiGatewayV2httpRequest.http_method may return incorrect method for standard v2 payloads #1080
Description
Hi. I have stumbled upon this issue, and I am not sure if there's something I am missing that would explain it, but it seems it could possibly be worth looking at.
In ApiGatewayV2httpRequest, the http_method is a top level field, but it's not really part of the standard ApiGatewayV2 payload, as far as I know. The actual method field is in requestContext.http.method.
By silently defaulting to GET when the field is missing (which is always the case for standard HTTP API v2 requests), user code that relies on this field could incorrectly handle requests, treating a POST, PUT, or DELETE as a GET. This could lead to incorrect routing, bypassed validation logic, or potential security issues if some logic relies on GET being safe.
As I said, I am not sure if there are reasons for that, but even looking at the test fixtures example-apigw-v2-*, the JSON examples do not present the httpMethod field in that location.
There is one test example_apigw_v2_custom_authorizer_v1_request that parses a custom authorizer v1 payload into ApiGatewayV2httpRequest and checks http_method. However, there's already a dedicated ApiGatewayV2CustomAuthorizerV1Request struct for that payload format.
The same applies to kind, method_arn, identity_source, and authorization_token — all are custom authorizer v1 specific fields that don't appear in standard HTTP API v2 payloads.
Possible solutions that I can think of:
- Deprecate these authorizer-specific fields on
ApiGatewayV2httpRequestand guide users toApiGatewayV2CustomAuthorizerV1Requestfor that use case - Add documentation warning users to use
request_context.http.methodinstead for standard HTTP API v2 requests
Happy to work on a small PR if it's confirmed to be an issue.