Negative match with LocationMatch directive

Forum Moderators: phranque

Message Too Old, No Replies

Negative match with LocationMatch directive

dfresh4130

9:10 pm on Jan 8, 2015 (gmt 0)

I have a LocationMatch directive where I'm using mod_substitute. I've found a few pages where my substitute is breaking the page and need to add a negative match to avoid them. The pages in question are identified by a unique parameter in the URL. I'm trying to use the below config, but the negative match isn't happening. Any suggestions on what can be used? Thanks

<LocationMatch "/(order|(?!order.*dir=[mM]anage.*)|search)">

phranque

1:08 am on Jan 9, 2015 (gmt 0)

the parameter is in the query string and therefore you won't be able to match that request with a LocationMatch directive.

http://httpd.apache.org/docs/current/mod/core.html#location

The enclosed directives will be applied to the request if the path component of the URL meets any of the following criteria:
...
the URL to be matched is a URL-path of the form /path/. No scheme, hostname, port, or query string may be included

lucy24

2:48 am on Jan 9, 2015 (gmt 0)

/(order|(?!order.*dir=[mM]anage.*)|search)

This is a pretty weird construction at the best of times. So let's take two steps back. If you lay out-- in English, not Apache-- what you want to do, we can probably find a way to achieve it.

dfresh4130

5:16 pm on Jan 9, 2015 (gmt 0)

This is for Apache 2.2.26. The servers are just proxypassing all traffic to tomcat backends and doing rewrites mainly. We're testing out a new monitoring tool that has the ability to capture browser timing data using a javascript. The javascript must be part of the head tag in the html so instead of modifying all of our code we tried the solution where we use mod_substitute to rewrite the head tag on the way out. It works fine except we've found some pages in our app that have multiple values of <head> in the page source so the substitute ends up breaking that page. I haven't found a way to tell mod_substitute to only modify the first matching entry on the page. Now I'm trying to figure out a way to exclude those specific URLs. After reading the docs link phranque provided it does seem I won't be able to match as deeply as I need to. Not sure if there are any other ideas to try.

Example good URL: http://www.example.com/order/en/US/path?dir=Update
Example broke URL: http://www.example.com/order/en/US/path?dir=manage

Original LocationMatch before finding broken pages:

<LocationMatch "/(order|search)">

Attempt to modify LocationMatch using a negative lookahead

<LocationMatch "/(order|?!order.*dir=[mM]anage.*|search)">

lucy24

8:12 pm on Jan 9, 2015 (gmt 0)

But by the time you get to the negative lookahead, you've already passed the generic "order" option-- and is that even valid lookahead syntax? Seems like it ought to be

/(order(?!.*dir=[mM]anage)|search)

Even then, I'd feel safer if the .* part were replaced by literal text-- at least something like

\?(\w+=\d+&)?

based on what could actually occur in this location. Lookaheads are not as persnickety as lookbehinds, but still.

This is, of course, all hypothetical, since the query-- the "dir" part --isn't part of the path so it can't occur in a <Location> section.

Gosh, it's tempting to say: Ditch the mod_substitute* angle and try doing the same thing in mod_rewrite instead ;)

* Confession: I have never met mod_substitute in my life and had to look at Apache docs to confirm that it isn't some arcane third-party mod. It doesn't come with much wiggle room, does it.