8000 [Routing] backreferences in requirements regex · Issue #8139 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Routing] backreferences in requirements regex #8139

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

Closed
skydiablo opened this issue May 26, 2013 · 8 comments
Closed

[Routing] backreferences in requirements regex #8139

skydiablo opened this issue May 26, 2013 · 8 comments
Labels

Comments

@skydiablo
Copy link
Contributor

query parameter requirements regex:

/**
 * @Route(
 *      "/search/{mac}", 
 *      name="MediaAccessControlVendorLookupSearch",
 *      requirements={"mac" = "(?:[[:xdigit:]]{2}([-:]))(?:[[:xdigit:]]{2}\2){4}[[:xdigit:]]{2}"}
 * )
 */
public function searchAction($mac) {
  ...
}

this will end in this exception

An exception has been thrown during the rendering of a template ("Warning: preg_match(): Compilation failed: reference to non-existent subpattern at offset 66...

thats right, but i have to use the referenz "\2", the routeMatcher need this behaivor

if (0 === strpos($pathinfo, '/vendorLookup/search') && preg_match('#^/vendorLookup/search/(?P<mac>(?:[[:xdigit:]]{2}([-:]))(?:[[:xdigit:]]{2}\\2){4}[[:xdigit:]]{2})$#s', $pathinfo, $matches)) {

so what is to do ?

@sstok
Copy link
Contributor
sstok commented Jun 1, 2013

As the first matching group is named, I guess the second one just starts with 1 not 2.

@lazyhammer
Copy link
Contributor

Looks like valid regex. What's your PCRE version, @skydiablo?

@skydiablo
Copy link
Contributor Author
PCRE Library Version => 8.12 2011-01-15

@Tobion
Copy link
Contributor
Tobion commented Jun 1, 2013

I found out why this doesn't work. The problem doesn't lie in the route matching, but in the URL generation.
In dev environment the params are checked against their requirements when generating a url. But it uses a slightly different regex (without (?P<mac>. This results in \2 not beeing available (it is \1 instead).
I also found a way to fix this. Will make a PR.

@skydiablo in the meantime you can set strict_requirements: null in config_dev.yml which will prevent this false check.

@Tobion
Copy link
Contributor
Tobion commented Jun 1, 2013

Thinking in more general terms, I come to the conslusion that supporting backreferences is impossible in the requirements check for URL generation. This is because the backreference is global for the whole regex but this check only tests against the single requirement.
So e.g. if your pattern was like "/{otherparam}/{mac}" then the backreferences would be totally different again. So I can fix your specific case where there is no other param before your mac with backrefences. But it's not possible to fix in general.

What might be possible is to use named backreferences instead. Then the position does not shift and it would work both for matching and generating urls.

@skydiablo
Copy link
Contributor Author

works great:

/**
 * @Route(
 *      "/search/{mac}", 
 *      name="MediaAccessControlVendorLookupSearch",
 *      requirements={"mac" = "(?:[[:xdigit:]]{2}(?P<macDelimiter>[-:]))(?:[[:xdigit:]]{2}(?P=macDelimiter)){4}[[:xdigit:]]{2}"}
 * )
 */

thx !

@Tobion
Copy link
Contributor
Tobion commented Jun 1, 2013

You are welcome.

You can also use relative references which is maybe more appropriate: (?:[[:xdigit:]]{2}([-:]))(?:[[:xdigit:]]{2}\g{-1}){4}[[:xdigit:]]{2}. Otherwise macDelimiter would be returned as a parameter (and set in the request params). It could have unwated sideeffects, e.g. when you use these params to generate a URL again.

@Tobion
Copy link
Contributor
Tobion commented Jun 1, 2013

I renamed the title, so people could find this issue if they have similar problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
< 36C9 div class="js-socket-channel js-updatable-content" data-channel="eyJjIjoiaXNzdWU6MTQ3NjUwMjMiLCJ0IjoxNzQ4MDg0Nzk5fQ==--914818186816fa5a0de1457414642a8756fe4f04990bccd7848da6288694e8ce" data-gid="MDU6SXNzdWUxNDc2NTAyMw==" data-url="/symfony/symfony/issues/closing_references/partials/sidebar?source_id=14765023&source_type=ISSUE" data-channel-event-name="issue_references_updated" >
Development

No branches or pull requests

4 participants
0