-
Notifications
You must be signed in to change notification settings - Fork 429
Bug: APIGatewayRestResolver fails to route when "/" appears at end of route name #1552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hey @walmsles, thanks for flagging this. API Gateway actually doesn't resolve trailing slash (unless that changed). It does work when you have a greedy path - /{proxy+}. Would you like to send a fix so we can support both? Tests should be able to catch any breaking change |
hmmm ... In my test project Lambda was executed for both trailing slash and not trailing slash. Let me clarify the behaviour - its been working this way from memory for a while now Will look at testing across the various resolvers as well. |
No at all. I changed the labels accordingly. The reason that API GW (ALB too IIRC) shouldn't work is because they are technically two distinct URIs - although we both know they are pointing to the same resource ("hello"). From memory, this is as old as Apache HTTPD (prolly even before). The closest authoritative source I can find is RFC 3986 on Path. |
Have read the RFC which is not exactly clear but looking at how URLs work from Apache HTTPD days - it is correct that /hello !== /hello/ so this is definitely not a bug. I did discover that both API Gateway REST and HTTPV2 route both /hello and /hello/ to the Lambda regardless of configuration of:
of course /{proxy+} will cause Lambda to be invoked always as expected and the router result is correct. Curiously RestAPI (V1) with a path defined as "/hello/" is deployed with a path of "/hello" and when you hit "/hello" and "/hello/" are all routed to the Lambda. For this reason, I wonder if the API gateway Resolvers and only API gateway Resolvers should ignore the trailing "/" when resolving routes? |
Tested further on HTTP Api - unable to register a definite route ending in trailing slash is ignored by the API gateway, and the route is simply not registered - unsure if this is documented behaviour, but that's how ap-southeast-2 is behaving today 🤷 Function URL has no routing applied to it, so the current behaviour makes sense. @heitorlessa wanted to get your thoughts on this one before I go off and do anything. My main thinking is APIGateway resolvers should route "hello" and "hello/" the same since if I did not use the router at all and just a lambda handler with an event - this is the outcome I get, so consistency of using Lambda Powertools or not should be a destination this project should head towards. |
Apologies for the delay, handling a sensitive issue in the last 24 hours. Back now.
This is surprising. I vividly remember REST API failing with authorization token when the route had a trailing slash.
I agree with you, we should match the experience on API Gateway. We should also have an E2E test to be sure this won't bite us in the future. It could be easier to test with ALB too via E2E as we already have one. Feel free to shout if you need any help with the E2E test. It should be easy to add a new function, but the details are here if you ever need: https://github.com/awslabs/aws-lambda-powertools-python/blob/develop/MAINTAINERS.md#run-end-to-end-tests Thanks a lot for digging on this! |
Closing as we're wrap to launch V2 |
|
Expected Behaviour
Given I am using APIGatewayRestResolver and I define a route as follows:
I expect the following 2 GET request URLs:
to return the same response:
Current Behaviour
Given I am using APIGatewayRestResolver and I define a route as follows:
When I use the following URL:
AWS Lambda Powertools returns a 404 not found response:
Code snippet
Possible Solution
Route resolution uses the
path
attribute of the AWS API Gateway Lambda event so that the 2 URLs (one with trailing "/") are no longer the same even though the API Gateway Service treats the routes correctly and executes the expected Lambda function.I would suggest that during route resolution trailing "/" characters be removed and not considered in route resolution.
Unsure if this would be considered a breaking change and whether any customers are using this behaviour - I would not think this behaviour would be in use y customers but am unsure 😬
Steps to Reproduce
Create and deploy the SAM CLI Hello World function then replace the app.py with my code snippet above which has replaced it with AWS Lambda powertools resolver once deployed try loading the API in browser with and without trailing "/" character
AWS Lambda Powertools for Python version
latest
AWS Lambda function runtime
3.9
Packaging format used
PyPi
Debugging logs
The text was updated successfully, but these errors were encountered: