Why does this 500?

Just on one server

[rocknbil]

Task: take all requests to /directory with exceptions of some file types and direct to a script for the purpose of outputting dynamic URL's based on the browser version.

Expected potential inputs (not counting css, etc.)
/directoryname
/directoryname/
/directoryname/index.html

Anything else will 404, which is what we want.

The commented lines are probably not efficient, but they generate 500's on this particular Linux dedicated server whereas they work fine on others. The uncommented name works, but it's a hard coded value, which will bloat up the .htaccess as it grows.

I'm "decent" at regexps and can't figure out why the thirds/fourth ones ([^/]+) 500. I've tested across a couple servers, it only fails on the one I need it to work on. :-)

RewriteCond %{REQUEST_URI} !\.css|\.js|\.gif|\.jpg|\.png$
RewriteRule ^(directoryname)\/*(.*) /cgi-bin/page-parser.cgi?d=$1&p=$2 [NC,L]
#RewriteRule ^(\w+)\/*(.*) /cgi-bin/page-parser.cgi?d=$1&p=$2 [L]
#RewriteRule ^(.+)\/*(.*) /cgi-bin/page-parser.cgi?d=$1&p=$2 [L]
#RewriteRule ^([^/]+)\/*(.*) /cgi-bin/page-parser.cgi?d=$1&p=$2 [L]
#RewriteRule ^([^\/]+)\/*(.*) /cgi-bin/page-parser.cgi?d=$1&p=$2 [L]

[jdMorgan]

Some of these will likely fail because they are recursive. If the rule's substitution (its "output path") matches the rewriterule's own pattern, then you'll get recursion in a .htaccess context.

The rule's output path must be explicitly excluded unless the pattern can be made specific enough to reject it... for example, by using something more specific than the troublesome ".*" subpattern there on the end. Remember, ".*" matches anything or nothing, but it matches as much as possible. If you really need a wild-card at the end of the RewriteRule pattern, then consider adding ".cgi" to the exclusions in the RewriteCond.

If you are using PCRE patterns, make sure your server is Apache 2.x; Apache 1.x will only support POSIX regular expressions, so "\w" will cause an error -- use [0-9A-Za-z_] there instead.

The quickest way to find the specific cause of a 500-Server Error is to examine the server error log file -- It will often tell you exactly what's wrong.

There is no need escape the "/" character in mod_rewrite patterns.

You could back-reference $1 in the RewriteCond of your currently-uncommented rule instead of re-parsing the whole %{REQUEST_URI} for a faster match. $1 already has had the leading part of the URL-path removed, so matching against it will be shorter.

Jim

[rocknbil]

I'll keep at it, I know to look in the error log, but there were some issues there too. I only have access to it via a CP and it isn't a "live" error log . . . ugh.

I was working up to eliminating the dots . . . the .*'s are only in there because that's how I got it to work. I just can't figure out why it's dying on the first one at the beginning of the pattern (the top directory.) I'd prefer to go with ([^/]+) for the top directory because I've no idea what they're going to set that as in the future. you_know-customers,well_some-of_them.


This is a new server, I'd be amazed if it's 1.0 . . . but I'll check, thanks.

[jdMorgan]

It is "dying" because the pattern ^"([^/]+)/(.*)$" nicely matches the previously-rewritten request for "/cgi-bin/page-parser.cgi", and thus loops, continuously rewriting "/cgi-bin/page-parser.cgi" to itself until the server detects this condition and throws a (fatal) error. Your error log will likely state this.

Please note my suggestion above to exclude request for "/cgi-bin/page-parser.cgi" or all ".cgi" filetypes from the rule, which would prevent this problem.

Apache version 1.3.3x is still widely-deployed.

Jim