Concerned that HTACCESS is killing the website

Hello,

I run a website for a shopping mall down here in Brazil and it’s experiencing some 503 errors on a regular basis.

I already checked, with the help of some coworkers, the PHP code of the website and it’s MySQL queries and nothing seems out of ordinary.

Researching a bit on Google, I found out some references to a loop on bad written HTACESS files that could bring a site down and I’m wondering if that could be the case here?

The website, without the HTACCESS, works like this, for each menu item:

website.com/index.php?module=cinema
website.com/index.php?module=lojas
et cetera

What the HTACCESS should do is rewrite the URL so the website modules are called like this:

website.com/cinema
website.com/lojas

Apparently it’s working but I’m not sure if the rules are badly written or not, can someone with more experience than me on this matter please take a look at it? I read somewhere that * is a bad practice but I have no clue on what to do here.

The full HTACCESS code is as follow:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?module=$1 [L,QSA]

Best regards,
Leandro Barbosa

Assuming this is all your htaccess code, this isn’t the source of your 503 errors. That’s a pretty standard rewrite.

I know of one or two people who indeed believe that .* is bad practice, but it isn’t a widely held opinion. For example, seemingly all the frameworks and CMSs use .*; the popular HTML5 boilerplate uses .*; even the official Apache documentation uses .*. The overwhelming consensus seems to be that it’s fine to use.

Yes it is.

I know of one or two people who indeed believe that .* is bad practice, but it isn’t a widely held opinion. For example, seemingly all the frameworks and CMSs use .*; the popular HTML5 boilerplate uses .*; even the official Apache documentation uses .*. The overwhelming consensus seems to be that it’s fine to use.

Thank you, Sir!

Guess I’m back to the PHP files then.

MuTLY,

Comments on your mod_rewrite code:

RewriteEngine On
[indent]Fine - ensures you're not in comment mode[/indent]
RewriteCond %{REQUEST_FILENAME} !-f
[indent]Fine - ensures you're not redircting when a existing file is requested (like favicon.ico)[/indent]
RewriteCond %{REQUEST_FILENAME} !-d
[indent]Same for directory requests[/indent]
RewriteCond %{REQUEST_URI} !=/favicon.ico
[indent]Not necessary - this duplicates the existing file directive two conditions above[/indent]
RewriteRule ^(.*)$ index.php?module=$1 [L,QSA]
[indent]Here is where the problem is. First, (.*) is a garbage collector and will match EVERYTHING (or NOTHING). Can your index.php script handle garbage? Can it handle NOTHING? Generally, the problem with (.*) is that it's loopy - constantly repeats the redirection.

To handle this "properly," I would collect the "acceptable" modules and rewrite your RewriteRule like this:

RewriteRule ^(cinema|lojas)$ index.php?module=$1 [L,QSA]

QSA? Are you expecting other key=value pairs? If not, DELETE the QSA as that could be used by someone attempting a SQL injection attack.[/indent]

You might benefit from reading the mod_rewrite tutorial linked in my signature as it contains explanations and sample code. It’s helped may members and should help you, tYou might benefit from reading the mod_rewrite tutorial linked in my signature as it contains explanations and sample code. It’s helped may members and should help you, too.

Regards,

DK

David,

Thank you for your detailed explanation on my htaccess code.

I’ll talk to my coworkers about it and I’ll make sure to examine the index.php file about your suggestions on how to handle the inputs

I’m already reading your tutorials on mod_rewrite as well.

Thanks again,
Leandro “MuTLY”

No problem, Leandro. That tutorial has helped SitePoint members for a lot of years.

Regards,

DK

Thanks mutly for such kind information about this error because i’m also face this problem

<snip>