-
Notifications
You must be signed in to change notification settings - Fork 397
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
Regression in route match regex in 1.18.0 #550
Comments
Thanks for opening your first issue here! We'll come back to you as soon as we can. |
I'm hoping someone will be able to take a look at this soon. We need the greedy pattern fix, but can't use 1.18.0 because of the regression preventing use of path parameters containing non-word characters. |
Looking into this now, missed it somehow |
PR created - re-reading the RFC for other chars we might be missing and will improve tests with it to be triple sure on it. Thanks again for providing a quick fix @moretension! |
Found other edge cases too, waiting for checks to complete then I'll release a patch version |
This is now available in PyPi and on Serverless Application Repository - 1.18.1 --- Could you double check this now works as expected for you @moretension? Thank you |
Fix confirmed in our unit tests, thanks! And thanks for going the extra mile to make sure you covered all the characters properly. |
The 1.18.0 release resolves the path regex greedy match problem in #520, but introduces a regression in the new regex pattern. To resolve the greedy match issue, #520 matches on the
\w
character set and on the non-word boundary (\b
) to ensure trailing path components following the match aren't captured. Unfortunately, this change also prevents match of path values containing non-word characters. Email addresses, URL-encoded values, and RFC 4122 UUIDs no long match route rules, because@
,%
, and-
are not included in the\w
character match set.Expected Behavior
APIGatewayResolver
route rules should match request path parameters containing@
,-
, and%
in addition to word characters. This was the matching behavior in the 1.17.x release.Current Behavior
No routes are matched if a path parameter contains a non-word character.
Possible Solution
The
_NAMED_GROUP_BOUNDARY_PATTERN
needs to be modified to include common non-word ASCII characters used in path components. Here's one possible pattern that seems to work while avoiding greedy capture:As shown in the REPL:
Steps to Reproduce (for bugs)
The following should call the
get_user_items()
function and print aResponse
JSON object containing theitems
object in the body. However, because the path parameter contains a non-word character, no route matches request path, and a 404 Response JSON object is printed instead.This works (albeit with the greedy match problem) in 1.17.x.
Environment
The text was updated successfully, but these errors were encountered: