Optimise RewriteRules/Conds

[Roy-Orbison]

The base URL determination is substantially faster if the input starts with the expected common substring (the initial match of the RewriteRule), rather than repeatedly recalculating the backreferences until the lengths match.

A demonstration that the updated version can take take two orders of magnitude fewer steps:
original: https://regex101.com/r/Lvi7Pu/1
updated: https://regex101.com/r/RXjdVZ/1

Also simplify previous rules where the match itself is not used in a condition or rewrite.

Q	A
Documentation	no
Bugfix	?
BC Break	no
New Feature	no
RFC	?
QA	no

Description

Regexps are a performance drain when unoptimised, especially when they rely of heavy backtracking and re-checking for matches. PCRE has built-in features to optimise for un/greedy matching which The BASE env var determination was not using. This patch optimises both the logic and the operators to perform much faster matching.

My only concern is that it appears as though the original did not always rewrite to the index.php file, but surely that can't be true: https://regex101.com/r/Lvi7Pu/2

I could modifiy this so that the rewritten path has only a relative prefix (except retain the / in the env var for backwards compat.), which makes more sense to me because rules are already matched against relative paths in .htaccess context.

[Roy-Orbison]

I've corrected the regexp to retain the original behaviour which I had misunderstood. In the example of the updated version (https://regex101.com/r/RXjdVZ/3), it appears as though the third, empty path input would match where the original wouldn't (https://regex101.com/r/Lvi7Pu/3), however the associated RewriteRule has been adjusted to require at least 1 character in the path. This effectively places the same constraint on the entire match as the (.+) portion of the original RewriteCond.

[weierophinney]

I've tested this in a project, and works as a drop-in replacement for the existing rewrite rules - thanks!