LocationMatch (and friends) and back references

[Graham Leggett <mi...@sharp.fm>]

Hi all,

It seems it is currently not possible to make reference to backreferences in regexes:

<LocationMatch ~ ^/(foo|bar)/baz>
  Something ${1}
</LocationMatch>

One of the tricky things to overcome to make this possible is that multiple LocationMatch'es might match, which makes the traditional ${1} pattern tricky to implement internally, as ${1} might be shadowed by another LocationMatch. As a possible solution to this, we could pass explicit variable names after the regex which are then populated into the subprocess environment and can be referenced elsewhere:

<LocationMatch ~ ^/(foo|bar)/baz/(.*) MYPREFIX MYFILE>
  Something ${MATCH_MYPREFIX}
  SomethingElse ${MATCH_MYFILE}
</LocationMatch>

Naming the backreferences explicitly has the advantageous side effect that we know how many of them there are (or we care about) and can pass or not pass the correct sized array to ap_regexec() as needed, meaning that supporting backreferences needs no performance penalty for people who don't use them.

Obviously the making the subprocess environment available to directives is a separate issue.

Thoughts?

Regards,
Graham
--

[Patch] LocationMatch (and friends) and back references

[Graham Leggett <mi...@sharp.fm>]

On 26 Dec 2013, at 11:45 AM, Graham Leggett <mi...@sharp.fm> wrote:

>> Why not using the standard regex syntax:
>> <LocationMatch ~ "^/(?<MYPREFIX>foo|bar)/baz/(?<MYFILE>.*)">
> 
> Is it supported by our current API?

It wasn't, but it is in this patch.

What this patch does is add all matching named variables from all matching LocationMatch/DirectoryMatch/FileMatch to the subprocess environment, uppercased, This opens up the possibility to reference elements of the URL from within directives that have access to the environment. Example like this:

<LocationMatch ^/(?<prefix>.*)/(?<name>.*)>
  # PREFIX and NAME are defined here
</LocationMatch>

Regards,
Graham
--

Re: LocationMatch (and friends) and back references

[Graham Leggett <mi...@sharp.fm>]

On 26 Dec 2013, at 10:13, Nick Gearls <ni...@gmail.com> wrote:

> Why not using the standard regex syntax:
> <LocationMatch ~ "^/(?<MYPREFIX>foo|bar)/baz/(?<MYFILE>.*)">

Is it supported by our current API?

Regards,
Graham
--

Re: LocationMatch (and friends) and back references

[Nick Gearls <ni...@gmail.com>]

Why not using the standard regex syntax:
<LocationMatch ~ "^/(?<MYPREFIX>foo|bar)/baz/(?<MYFILE>.*)">


On 26-12-2013 08:43, Graham Leggett wrote:
> Hi all,
>
> It seems it is currently not possible to make reference to backreferences in regexes:
>
> <LocationMatch ~ ^/(foo|bar)/baz>
>    Something ${1}
> </LocationMatch>
>
> One of the tricky things to overcome to make this possible is that multiple LocationMatch'es might match, which makes the traditional ${1} pattern tricky to implement internally, as ${1} might be shadowed by another LocationMatch. As a possible solution to this, we could pass explicit variable names after the regex which are then populated into the subprocess environment and can be referenced elsewhere:
>
> <LocationMatch ~ ^/(foo|bar)/baz/(.*) MYPREFIX MYFILE>
>    Something ${MATCH_MYPREFIX}
>    SomethingElse ${MATCH_MYFILE}
> </LocationMatch>
>
> Naming the backreferences explicitly has the advantageous side effect that we know how many of them there are (or we care about) and can pass or not pass the correct sized array to ap_regexec() as needed, meaning that supporting backreferences needs no performance penalty for people who don't use them.
>
> Obviously the making the subprocess environment available to directives is a separate issue.
>
> Thoughts?
>
> Regards,
> Graham
> --
>
>
>
>