Skip to content
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

fix Weighting calculation for path converters and add tests #3018

Closed
wants to merge 1 commit into from

Conversation

tgbugs
Copy link

@tgbugs tgbugs commented Jan 16, 2025

Fix issue #2924 where Rules with dynamic elements would take priority over rules with static elements of the same length.

The underlying issue was that the ordering for rules was backwards with regard to number of argument weights. In order to ensure that static elements match first the shortest rule must be tested first.

To ensure that a RulePart that contains a path converter does not incorrectly take priority over other RuleParts that are part of other Rules that should have priority, RuleParts containing a path converter are assigned an infinite number of argument weights because they can consume an arbitrary number of url path elements when matching.

With this change, two consecutive path converters give priority to the first converter. In general two consecutive path converters with different names cannot have consistent or predicatable behavior (where would you cut?). Tests are updated accordingly. Might consider making back to back path converters an error.

fixes #2924

Fix issue pallets#2924 where Rules with dynamic elements would take priority
over rules with static elements of the same length.

The underlying issue was that the ordering for rules was backwards
with regard to number of argument weights. In order to ensure that
static elements match first the shortest rule must be tested first.

To ensure that a RulePart that contains a path converter does not
incorrectly take priority over other RuleParts that are part of other
Rules that should have priority, RuleParts containing a path converter
are assigned an infinite number of argument weights because they can
consume an arbitrary number of url path elements when matching.

With this change, two consecutive path converters give priority to the
first converter. In general two consecutive path converters with
different names cannot have consistent or predicatable behavior (where
would you cut?). Tests are updated accordingly. Might consider making
back to back path converters an error.
@pgjones
Copy link
Member

pgjones commented Feb 16, 2025

This doesn't fix #2924 when I try to reproduce. I'm also not certain #2924 requires fixing.

@davidism davidism closed this Feb 17, 2025
@davidism davidism reopened this Feb 17, 2025
@pgjones
Copy link
Member

pgjones commented Feb 28, 2025

Closing following discussion in #2924.

@pgjones pgjones closed this Feb 28, 2025
@tgbugs
Copy link
Author

tgbugs commented Feb 28, 2025

I don't think this should be closed because this fixes issues beyond those described in #2924. Without the fix that I implement here it is impossible to get correct behavior and I and anyone else affected would have to carry a patch.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

url matching order changed versus 2.2
3 participants