-
Notifications
You must be signed in to change notification settings - Fork 408
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
ApiGatewayResolver root routes and strip_prefixes #646
Comments
Nice one @BVMiko , i put in a review comment for adding a test case. Otherwise, i was thinking whether it should be from aws_lambda_powertools.event_handler.api_gateway import ApiGatewayResolver
app = ApiGatewayResolver(strip_prefixes=["/some-path"])
@app.get("")
def my_func():
return {'execution_status':'success'} As the original request path of |
I believe that the common standard among other routing frameworks is that all paths should have a leading slash, so As for implementation, Flask and FastAPI both seem to do things differently by building and caching the full paths within each route. However ExpressJS, looks like it handles routing similar to the current ApiGatewayRouter though it does ensure a leading slash. |
@BVMiko - agreed. But strip_prefix is supposed to remove the matching prefix from the request. And that this is on the context of "strip_prefixes" is "/custom-mapping", and the actual request is without a trailing "/" and would look like "/custom-mapping". So naturally I would except the resulting path to be "". Internally this was not happening due to the addition of a "/" for the starts with check. Because we wanted to allow for "/pay" and "/payment" strip prefixes to be set in any order. As "/pay" would be a partial match. It would remove before "/payment". So the ultimate solution could just be to reverse the order of the prefixes and remove the "/" we add in the starts with check. |
@BVMiko - thinking it through. If the request path resolves to a empty string (""), after the strip prefixes. Then it makes sense that the base is now actually "/". We just need to document that there is no difference between a request path of "/pay" and "/pay/" when the strip prefix is "/pay". |
@michaelbrewer - I updated the testcase and the docs to reflect the new explicit change; let me know if you'd like the wording modified. |
Fixed in v1.20.2. |
I ran into an issue when using a route with the rule
"/"
along withstrip_prefixes
feature. This rule is unable to trigger due to thepath
variable being reduced down to an empty string instead of a forward slash.Expected Behavior
Accessing
domain.com/some-path
would executemy_func()
.Current Behavior
Accessing
domain.com/some-path
returns a 404. Of note though, accessingdomain.com/some-path/
(note the trailing slash) will executemy_func()
.Possible Solution
Add an conditional here which will map an empty string to
"/"
.Steps to Reproduce (for bugs)
some-path
https://CUSTOMDOMAIN/some-path
andhttps://CUSTOMDOMAIN/some-path/
and note the different resultsThe text was updated successfully, but these errors were encountered: