This question is a re-opening of RewriteRule - Caret ^ - Match because the actual question has not been answered by the accepted answer.
I am confused about these rewrite rules in a .htaccess
file which is supposed to redirect all requests for non-existing files and directories to the front controller
# Send Requests To Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
The original question was: How is it possible that a caret can match the whole URL if it is a position anchor?
Please note, the highlighted part "whole". I know that the caret matches the beginning of a line and thus the rule is always hit, but the caret does not consume any characters and according to the official Apache docs, "the Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern."
Moreover, if the .htaccess
file is placed in a directory, the leading /
of the URL which represents the directory, is not part of the match (again, see Apache docs, 2nd bullet point below "What is matched").
In summary, if the URL is something like https://my-domain.tld/api/foo
the relative URL seen by the rewrite rule is api/foo
, the caret ^
matches the beginning and after substitution we end up with index.phpapi/foo
. Essentially, index.php
is put in front of the original URL.
How does this work? A file named index.phpapi/foo
does not exist. I would have expected a 404 Not Found result code.
CodePudding user response:
# Send Requests To Front Controller... RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ index.php [L]
As you state, the caret (^
) does not actually match anything. It simply asserts the start-of-string, which will be successful for everything (every requested URL-path). And that is all it needs to do here... be successful.
The regex $
(end-of-string anchor) would have the same result. As would .?
(an optional single character), etc.
but the caret does not consume any characters and according to the official Apache docs, "the Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern."
It doesn't literally just replace the part that is "matched". It replaces the entire URL-path that is matched by (or satisfies) the pattern. The pattern ^
successfully matches (or satisfies) everything.
Moreover, if the .htaccess file is placed in a directory, the leading / of the URL which represents the directory, is not part of the match (again, see Apache docs, 2nd bullet point below "What is matched").
Yes. (Although, strictly speaking, it is the directory-prefix that is removed. And the directory-prefix always ends in a slash. The directory-prefix is the absolute filesystem path of the location of the .htaccess
file.)
and after substitution we end up with index.phpapi/foo. Essentially, index.php is put in front of the original URL.
No, that is not what happens.
As noted above, the substitution string replaces the entire URL-path on success. index.php
replaces api/foo
in its entirety. api/foo
successfully matched (or satisfied) the regex ^
.
If you literally wanted to replace just the part of the URL-path that is matched by (part of) the RewriteRule
pattern then you would need to manually reconstruct the entire URL-path by capturing the other parts of the URL-path. (This is a common task when you want to replace just a single word in the requested URL-path.)
end up with
index.phpapi/foo
To do that you would indeed need to match everything, capturing a backreference and constructing the URL-path. For example:
:
RewriteRule (.*) index.php$1 [L]
But as you say, this will likely result in a 404.
Aside:
Strictly speaking, the ^
is not optimal here. This is successful for the directory itself (an empty URL-path). However, the first condition (RewriteCond
directive) excludes directories, so the rule is not successful anyway. The pattern does not need to be successful for literally everything, just everything other than the directory itself. For example, the following would be an improvement (ie. fail early):
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . index.php [L]
This "matches" just a single character. It does nothing with this match, it is simply "successful". It fails to match the directory itself (but the first condition would also cause the rule to fail).
This rule does not need to rewrite the directory to index.php
because mod_dir issues a subrequest for index.php
(the DirectoryIndex
) when the directory itself is requested.