Have Geek Brain

.htaccess when faced with GET parameters

Here is my .htaccess file:

RewriteEngine on

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

Which should mysite.com/?p=request

only be redirected to if request

not a file. But this does not match the type request correctly http://mysite.com/auth.php?openid.ns=http%3A%2F

due to %2F

(auth.php exists). I don't understand why it overshadows ... ideas?

Edit: Guys, I'm putting emphasis on %2F

(which is a forward slash in the opposite direction) because it works great when that character is not there

To be clear

I am getting 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 happened any time% 2F appeared in the url. My app was breaking this error and spitting out a deceptive 404 that might be less intimidating to the end user. Really has nothing to do with .htaccess. More details in my answer below.

0


a source to share


5 answers


Not a problem AllowEncodedSlashes

. He pressed a rule mod_security

that forbids http://

in the parameters to prevent file injection. They canceled it for me.



0


a source


Perhaps you need to enable AllowEncodedSlashes

, which is disabled by default? When this directive is disabled, requests containing encoded backslashes and backslashes (i.e.% 2F and% 5C) are rejected with 404.



I vaguely remember seeing this issue on MediaWiki where all sorts of fun things have to be done when avoiding titles etc. to avoid different ups and downs at different levels of request processing. It turns out there are quite a few things in the land of Apache, how to tinker with PATH_INFO, etc., which leaves no end to hell for all of us.

+3


a source


Can you be sure that doesn't mean it?

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -f

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

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

if it doesn't have the full path to the auth.php file, it won't find it. I got this information here:

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

0


a source


This is probably due to the fact that you don't have parentheses in your regex, so no capture occurs. The following works for me:

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


a source


I'm glad you understood that you have a hosting provider. have you found other slash combinations that worked and withstood them?;)

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

Perhaps this is the real answer. if the application expects to do something internally with the "http" URL, it needs to know to add it to the beginning at the last crucial moment.
0


a source






More articles:


All Articles