Home/ Questions/Q 8208499
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T09:23:28+00:00

I can’t understand why redirect depends on RewriteRule (not on RewriteCond). My .htaccess: Options

  • 0

I can’t understand why redirect depends on RewriteRule (not on RewriteCond).

My .htaccess:

Options +FollowSymLinks +SymLinksIfOwnerMatch

<IfModule mod_rewrite.c>
RewriteEngine on

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ true.txt

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ false.txt
</IfModule>

Root folder contains:

true.txt (contains ‘true’)
false.txt (contains ‘false’)
test.txt (contains ‘test’)

If I try to open test.txt I get true and if I try to open nonexist.txt i get true too.

Now I change my .htaccess:

...
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ $1
...

And now if I try to open test.txt I get test and if I try to open nonexist.txt i get false.

UPDATE: Thanks for answers, I understood how it works but one problem still exists.
If I try to check ‘if file exists’ in another directory it always returns false.

/files/test.txt
/script/.htaccess
/script/false.txt
/script/true.txt

now my .htaccess looks like

RewriteCond %{REQUEST_FILENAME} .*(true|false).*$
RewriteRule .* - [S=2]

RewriteCond %{DOCUMENT_ROOT}/files/%{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ true.txt [L]

RewriteCond %{DOCUMENT_ROOT}/files/%{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ false.txt [L]

I always get false.
I also tried RewriteCond ../files/%{REQUEST_FILENAME} and also always get false result.

If I move test.txt in script folder then and change RewriteCond %{REQUEST_FILENAME} all works fine.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s because of the way mod_rewrite works: the user requests test.txt, mod_rewrite catches the requests and rewrites the URI to false.txt, then it makes a second pass, by sending an internal request for false.txt, which is caught and rewritten to true.txt. Then a third pass is made, the request is caught and rewritten to true.txt, but since the URI stays the same, no more passes are made.

    It’s rather counter-intuitive, but there’s logic to it. Here’s the control flow diagram from the docs:

    control flow diagram of mod_rewrite

    The [L] flag is often advertised as a magic bullet to stop the recursion, but in fact it just ensures that once a request matches a pattern, then the execution stops and no further processing will take place in that pass, but the internal request will be sent out anyhow, so a second pass is made through the same ruleset. The execution stops only if the URI is unchanged after a pass.

    re: update
    Your problem is, the REQUEST_FILENAME environmental variable actually holds a path (by default the full filesystem path, but there are a few twists to that), so %{DOCUMENT_ROOT}/files/%{REQUEST_FILENAME} ends up being something horrible.

    As for a solution… well, it’s tricky, I think. It’d be a lot easier if the .htaccess were in root. The only solution I can think of right now is:

    RewriteEngine on

RewriteCond %{REQUEST_URI} script/(.*)$
RewriteCond %{DOCUMENT_ROOT}/files/%1 -f
RewriteRule .* true.txt [L]

RewriteCond %{REQUEST_URI} !(true.txt)|(false.txt)
RewriteRule .* false.txt [L]

    It’s rather ugly, and not very scalable or portable. In the first condition I get the file’s name, in the second I check if it exists, and if it does, it’s true. Everything else is false. Then again, if the files directory is also in the scope of the .htaccess, it’s easier and nicer by magnitudes.

    • 0