Understanding 1 line of an .htaccess file

Question

I have the following .htaccess at the moment. This is a dummy copy paste from here and there, but I would like to understand a little bit more about what is happening here.

So, I would like to request your help in order to properly comment those .htaccess instructions:

#1) The rewrite is probably on. Still, to make sure:
RewriteEngine On

#2) If we need to overwrite some server definitions:
#php_value upload_max_filesize 15M
#php_value post_max_size 15M
#php_value max_execution_time 200
#php_value max_input_time 200

#3) If we want to exclude some files from URI rewriting we do:
RewriteCond %{REQUEST_FILENAME} !^(filename1|filename2)

#4) If we want to exclude those directories from URI rewriting we do:
RewriteRule ^(dir1|dir2|dir3) - [L]

#5) What are we saying here ?
RewriteRule ^\.htaccess$ - [F]

#6) What does those lines mean ? How are those 3 Condition/Rule blocks related ?
RewriteCond %{REQUEST_URI} =""
RewriteRule ^.*$ /public/index.php [NC,L]

RewriteCond %{REQUEST_URI} !^/public/.*$
RewriteRule ^(.*)$ /public/$1

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ - [NC,L]



#7) Should we have this, because it's somehow more controlled, OR should we use: !-f: ?
RewriteCond %{REQUEST_FILENAME} !\.(js|JS|Js|jS|ico|Ico|ICO|zip|ZIP|Zip|rar|RAR|Rar|mov|MOV|Mov|MPEG4|Mpeg4|mpeg4|mp4|Mp4|gif|GIF|Gif|jpg|JPG|Jpg|jpeg|JPEG|Jpeg|PNG|Png|png|CSS|Css|css|DOC|Doc|doc|PDF|Pdf|pdf|DOCX|Docx|DocX|docX|docx|WMV|Wmv|wmv|MPEG|Mpeg|mpeg|AVI|Avi|avi|MPG|Mpg|mpg|FLV|Flv|flv|PPT|Ppt|ppt|PPTX|PptX|Pptx|pptx|txt|TXT|txt)$

#8) Are we redirecting all requests inside public folder, to index.php ?
RewriteRule ^public/.*$ /public/index.php [NC,L]

Care to comment/answer on my 1 to 8 comments ?
Thanks a lot in advance.

ps- should I place all those questions on separate posts perhaps?

UPDATE: I do have A LOT of questions here that I cannot understand. When we don't understand our own questions, it's a bad sign. The best thing to do is, indeed, split all this into smaller parts. This being said:

About point 3):

So, here:

RewriteCond %{REQUEST_FILENAME} !^(filename1|filename2)

We are comparing, let's say:

/home/mysuser/public_html/something.php

with:

filename1 OR filename2

We have the ^ that point us to the

"start of the string"

. Since filename1 doesn't start with a / but the

REQUEST_FILENAME

will, that condition will never be the case.

HOWEVER, we do have a ! that negates the all thing.

So,

We are comparing (again, for example):

/home/mysuser/public_html/something.php

with something that "doesn't start with" (the ^ part) / (because our filenames will not have a slash at the beginning) hence, the all condition will always evaluate true.

Having a condition that will ALWAYS evaluate true or ALWAYS evaluates false, isn't that great. So I believe. I better leave it then.

IF ALL THOSE ASSUMPTIONS ARE CORRECT AND PRECISE: Three questions:

1) It seems that, if we can, somehow, remove the ^ part to something that match the all string, will that be preferable?

2) Is there any other way for doing the requested thing: "What to code if we want to exclude some files from being redirected ?"

3) By looking to this htaccess file, I can't understand: What rule should follow THIS condition?

Can I have your help to figure those out?

Thanks a lot again.

Answer 1

1. RewriteEngine on is always required to enable the runtime rewriting engine.
2. Has nothing to do with mod_rewrite.
3. This condition will always be true as the REQUEST_FILENAME value does always start with a /. Note that this is the absolute file system path and not the URI path (i.e. REQUEST_URI).
4. Yes, using the - substitution doesn’t change the URI but stops the current rewriting process when combined with the L flag. Note that the pattern will match any path that starts with these prefixes and not just directories.
5. This rule is probably to deny access to the .htaccess file. However, your web server should already cover this.
6. The first rule should probably rewrite a request of / internally to /public/index.php. However, this rule will never be applied as the condition will never be fulfilled as REQUEST_URI is never empty but at least /. The second rule will do the same for any URI path unless it already starts with /public/. And the third rule will pass through any request that can be mapped onto an existing file.
7. This list of file name extensions is quite extensive. The uppercase/lowercase issue can be handled by using the NC flag instead. But this rule shouldn’t be applied for existing files anyway as the previous rule will already catch it.