mod_rewrite debugging/testing tool

Looking for a standalone rewrite tool to help build rewrite

[broniusm]

Can someone recommend a stand-alone utility (command line or web would be awesome) against which I can develop, test, and debug my apache mod_rewrite scripts? I can envision such a web utility that would allow the developer to enter a typical url, and the utility would respond with what the rewritten url would look like. A good tool would even help one build strings.

My apologies up front if this has been posted. I sought but could not find. If there is such a thread, please post here so folks could find the resource!

thanks :D

[jdMorgan]

I don't know of anything matching your description.

There are a lot of on-line ".htaccess file generators" but they only generate code -- usually ranging from "non-optimal" to "awful" because they must, by definition, be generalized. In particular, they often use more than one ".*" pattern in rules, when far better patterns can be used if the author knows the details of the URL structure. Just as an example, if friendly URLs have been used to separate keywords with slashes, then the generator may output something like:

RewriteRule ^(.*)/(.*)/(.*)/(.*)$ /showproduct.php?cat=$1&size=$2&color=$3&finish=$4

Because ".*" will match *anything* and match as many characters as possible, the effect of this is that the regex parser must make n-3 passes trying to get a match, where n is the length of the requested URL. On the first pass, it tries to match the entire URL into the first ".*" pattern. It then fails, because it needs a slash to match. So it has to "back off" one character at a time from the end of the requested URL, until it finds the first slash. It then gets a match, but subsequently fails because it needs a second slash to match the second sub-pattern. So, the process repeats, again failing because it needs a third slash. It will finally match, but only after many iterations.

Note also that because ".*" will match anything, the pattern will match the intended URL example of
/widgets/large/blue/fuzzy, but it will also match the "longer" URL /widgets/discount/large/blue/fuzzy
and any other longer URLs, leaving $1 with the value "widgets/discount". This can lead to unexpected results, especially unexpected interactions between mutliple rules.

A better solution, given that the author knows that slashes always delimit the values, would be:

RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/?$ /showproduct.php?cat=$1&size=$2&color=$3&finish=$4 [L]

which is much, much faster to process and eliminates the abiguity-realted problem of accepting "longer" URLs.

Another flaw is that a lot of them generate patterns like:

RewriteRule ^.*(sub-pattern).*$ /new_url

which is wasteful, since

RewriteRule (sub-pattern) /new_url [L]

is entirely equivalent in almost all cases.

Many of them are also oblivious to the availability of mod_rewrite's [NC] flag, which results in further inefficiencies.

Not all of them suffer from all of these problems; Just be aware of the possible limitations if you use them.

There is also an on-line "regular-expressions tester" that can be useful.

I suggest you carefully develop and test just a few rules at a time, rather than counting on a one-size-fits-all tool to generate all of your rules at once. I use a "test" subdomain or a separate test server to do this, so that that the test rules don't affect a live site.

Please note that we don't encourage tool URL drops here at WebmasterWorld.

Jim

[broniusm]

Thanks for the rewrite insight ;)

I'm surprised to read that there isn't some web app (or even command line util) that simply acts as a front end to pass a couple strings (url and re) to mod_rewrite and responds with the would-be resulting url. You know, completely bypassing apache for the sake of testing/learning/debugging.

It does sound feasible, doesn't it? (and in my experience, any time I've had a quality idea, I google it and discover it's already been done (_with_ css! :) )

[extras]

The best debugging tools for mod_rewrite is RewriteLog.

Although you may not want to use it on a production server,
it's relatively easy to setup an Apache on test server (or even on Free VMware Player) and set RewriteLog with high RewriteLogLevel.

Other than that, you can use QUERY_STRING (and ENV variables, in some cases) as a sort of debug output, especially when you are testing on a server without access to httpd.conf.

Also, simple syntax check can be performed with httpd (or apache2) command.

example:
apache2 -t
or
apache2 -r -f httpd.conf.new