More fun with Rewrite - how specific should I be?

[csdude55]

I have a rewrite that looks like this:

RewriteCond %{REQUEST_URI} !^/(?:foo|bar)/(?:.+)\.php$ [NC]
RewriteRule ^(foo|bar)/(.+)/?$ /foo/view.php?cat=$1&id=$2 [QSA,NE,NC,L]

My question is, should I use (foo|bar) in the RewriteCond?

My initial logic is that, yes, I should make it as specific as possible so that it can discard non-matches faster.

But in retrospect, I think that I'm reading one regex, then reading a second regex, then moving on to the rule and reading a third regex. That third regex may be totally pointless, since this would match the exact same:

RewriteCond %{REQUEST_URI} !\.php$ [NC]
RewriteRule ^(foo|bar)/(.+)/?$ /foo/view.php?cat=$1&id=$2 [QSA,NE,NC,L]

Buuuuut, it might be faster to process when (foo|bar) doesn't match (in which case the original would run one regex, where the second would run two).

I don't really have a way to bench test this, so what do you guys and gals think?

[phranque]

i would go with the second version.
it looks more efficient but more importantly it is far simpler to understand and therefore easier to maintain while still being sufficient.
if it were in fact less efficient, the difference is probably insignificant.

[csdude55]

That's kind of my thought, too... when in doubt, I usually go for the least amount of code necessary. But in this case I can't test for speed, and I hate to give up 50ms on each page load in exchange for easier-to-read code that I'll probably never look at again :-/

[lucy24]

Agreed. The body of the rule has already said that you start with (foo|bar), so there's no point in saying the same thing over again in the Condition. Always remember that a RewriteCond is only ever read at all if the pattern in the RewriteRule matches; it's a "two steps forward, one step back" system.

That's assuming there are URLs other than
/foo/view.php
potentially involved, like /bar/anything.php or /foo/something-other-than-view.php

Didn't we establish earlier that [NE] isn't necessary for the & character in a query string? (Got a vague idea phranque looked it up in the docs.) Will do no harm, but it's another three bytes to read through on every request, at least while it remains in htaccess.

[csdude55]

Didn't we establish earlier that [NE] isn't necessary for the & character in a query string?

Umm, I might have missed that... I remember mentioning it and you mentioned that you hadn't considered the & in the query string, but I don't remember anyone finding otherwise in the docs. I was going off of this statement:

By default, special characters, such as & and ?, for example, will be converted to their hexcode equivalent. Using the [NE] flag prevents that from happening.
[httpd.apache.org...]

[lucy24]

I might have missed that

:: search, search, search ::

Here [webmasterworld.com] it is, at the bottom of the Negative Match thread from about a month ago. (I tend to remember threads where I said something factually incorrect and someone set me straight. It's one way to learn, I guess :() Turns out it wasn't phranque but w3dk, but I suppose it all averages out in the end.

[csdude55]

I tend to remember threads where I said something factually incorrect and someone set me straight.

I used to be like that, but now there's just not enough room in the database for all that... LOL

A quick test found that w3dk is right, so I don't understand why the docs had to make it so confusing. Why specifically say that & would be converted to hexcode if it's not?

[lucy24]

Why specifically say that & would be converted to hexcode if it's not?

I thought it meant that if you are demented enough to have an & in the middle of an URLpath (not in the query string), that would be percent-encoded. But a quick detour to the test site tells me this is not the case. In fact the only things I could find that come through with percent-encoding are # (%23) and % itself (%25).

:: insert "extreme puzzlement" emoticon here ::