RewriteRule & encoded + sign unexpected results

Stump the chump trivia test for your next Apache guru get together

[KenB]

Today I discovered a totally unexpected behavior when the .htaccess RewriteRule passes an encoded plus sign (%2B) to a query string. For example if you take and urlencode the URI "/foo/widget 2+.html" you get "/foo/widget+2%2B.html". Now take this URI and pass it to a querystring via the following RewriteRule:

RewriteRule ^(foo|bla|ick)/(.*)\.html$ /index.php?$1=$2 [L,QSA]

Now in index.php take and decode the variable $foo using the urldecode function:

echo urldecode($foo);

What would the result be?

.

.

.

.

If you said "widget 2+" you would be wrong. What you end up with is "widget 2 " where the plus sign ends up being another space.

In order to get the plus sign back you would need to do the following:

$foo=urldecode($_SERVER['REQUEST_URI']);
$foo=str_replace("/foo/","",str_replace(".html","",$foo));
echo $foo;

Apparently, best I can tell when the RewriteRule passes %2B to a variable it converts the %2B back into a plus sign and then urldecode() converts the plus sign into a space.

I wasted half the morning figuring that one out.

So the next time you need to stump the chump at some get together of Apache gurus ask them the above scenario and see if they get it right. Odds are they won't.

[KenB]

Thinking more on this issue. I think what is really happening is that Apache is decoding the string as the RightRule passes it over to the query string. Thus using urldecode() becomes redundant, thus the plus sign disappears. So unless someone does what I do and bury the urldecode instruction in a larger custom function for cleaning variables they could simply use $foo straight without using urldecode.

In my case since I use a separate multi-use function to sanitize encoded such strings I have to parse the REQUEST_URI as I described at the end of my post above.