CODEWITHSUNDEEP
.htaccess
mpen
mpen

Reputation: 282865

.htaccess clashing with GET params

Here's my .htaccess file:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* ?p=$0

Which should redirect to mysite.com/?p=request only if request is not a file. But, it's improperly matching a request like http://mysite.com/auth.php?openid.ns=http%3A%2F because of the %2F (auth.php does exist). I don't understand why that's screwing things up... ideas?

Edit: Guys, I put emphasis on %2F (which is a forward slash btw) because it works fine when this character isn't in there

To be clear,

I get a 404 for this page: http://mysite.com/auth.php?openid.ns=http%3A%2F

but not this page: http://mysite.com/auth.php?openid.ns=http%3A

Just FYI, I really screwed this question up. It was a 403 error that occurred anytime %2F appeared in the URL. My app was catching this error and spitting out a deceptive 404 which might be less frightening to the end user. Really had nothing to do with .htaccess after all. More details in my answer below.

Upvotes: 0

Views: 1227

Answers (5)

ifatree
ifatree

Reputation: 843

glad you got it figured out with your hosting provider. did you find other slash combinations that worked and confront them about it? ;)

a non-apache-related answer would be to not pass the known "http://" string in the parameter at all. looking at my stackoverflow account page as an openID example, it doesn't even seem to store "http://" at all, just "me.yahoo.com/a/swxth....".

maybe that's the real answer. if you app expects to do something internally with an "http" URL, it should know to add it to the beginning at the last responsible moment.

Upvotes: 0

mpen
mpen

Reputation: 282865

Wasn't a AllowEncodedSlashes problem. It was hitting a mod_security rule that forbid http:// in the params to prevent file injection. They whitelisted it for me.

Upvotes: 0

Rob
Rob

Reputation: 48369

Is it possible you need to enable AllowEncodedSlashes, which is off by default? When this directive is switched off, requests containing encoded forward and back slash characters (i.e. %2F and %5C) are refused with a 404.

I vaguely remembered seeing this issue in MediaWiki, where all sorts of fun things have to be done when escaping titles and so on, to avoid the various cock-ups at different levels of request handling. Turns out, quite a lot of things in Apache land like to mess around with PATH_INFO and suchlike, which causes no end of hell for the rest of us.

Upvotes: 3

Ayman Hourieh
Ayman Hourieh

Reputation: 137146

It's probably related to the fact that you don't have parentheses in your regex so capturing does not happen. The following works for me:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ ?p=$1 [L,QSA]

Upvotes: 0

ifatree
ifatree

Reputation: 843

can you make sure you don't mean this?

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -f

to test what the value of the variable is, use something like:

RewriteRule (.*) http://www.google.com/?test=%{REQUEST_FILENAME} [L]

if it doesn't have the full filepath to your auth.php file, it won't find it. i got this info here:

http://mail-archives.apache.org/mod_mbox/httpd-bugs/200812.mbox/

Upvotes: 0

Related Questions