Fix path support after unlimited optional placeholders

[andrewnicols]

When using a route which contains both an unlimited optional placeholder, and another optional placeholder afterwards, the incorrect values are collected.

For example, given the following route:

/go/to/[{location:.*}[/info/{subpage}]]

The following behaviour is currently observed:

• route: /go/to/[{location:.*}[/info/{subpage}]]
• url: /go/to/australia/perth/info/about
• location: 'australia/perth/info/about'
• subpage: ''

Note that the location contains /info/about and the subpage is empty.

This is inconsistent with the behaviour where an unlimited value is not used:

• route: /go/to/[{location}[/info/{subpage}]]
• url: /go/to/australia/info/about
• location: 'australia'
• subpage: 'about'

In the case of the unlimited optional path, the expected behaviour is: The correct value would be:

• route: /go/to/[{location:.*}[/info/{subpage}]]
• url: /go/to/australia/perth/info/about
• location: 'australia/perth'
• subpage: 'about'

This commit change updates the route dispatcher to reverse the order of the routes when adding routes to the router, which brings the unlimited path placeholder format inline with limited path placeholders.

[andrewnicols]

Note: 1.3.0 is also impacted by this bug.

[andrewnicols]

Any chance of a review on this issue?

Thanks

[andrewnicols]

I believe I've solved all of the GHA failures.

[lcobucci]

@andrewnicols I'll have a look soon.

The problem here is that this will affect the performance of the matching process. Also it isn't really a bug, as unbound parameters aren't officially supported - thus the lack of tests for it.

[bwoebi]

I don't think this needs a fix. The regex should be simply ungreedy, i.e. {location:.*?}.