I manage a large number of PHP applications using front controllers and the following htaccess file:
FallbackResource /index.php
Yes, that is the entire file (for each application)!
However, a few of the sites are in subfolders, necessitating the following change:
FallbackResource /subfolder/index.php
As you could probably guess, the /
at the beginning means that the path is relative to the site/vhost, and here the path needs to be relative to the directory.
(If I were using mod_rewrite
for this instead of mod_dir
, I would have to add a RewriteBase
to each subdirectory as needed, in a similar fashion.)
I thought that I could get around this by doing:
FallbackResource index.php # No slash!
However, when the site's rewrites contain slashes, for example, if the application is /store/
and the path within it is products/1234
, then Apache looks for /store/products/index.php
instead of /store/index.php
and returns a 500 with the following message in the log:
Request exceeded the limit of 10 subrequest nesting levels due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
I would have thought that the FallbackResource
path is relative to the .htaccess file in which it is configured, but it seems that it is actually relative to the requested URL.
Is there a way to have FallbackResource
act the way that I expected?
I can use it the way it is if that's the answer, but it would make it a lot easier to manage the sites that I have if this can be done. The sites use the same basic code with different themes and database connections, and the way it works now I have to modify the htaccess file every time we deploy a new version of the code (because it is checked into Git). If we can make it that someone doesn't have to remember to make this modification every time, that would be really great.
I don't think this is possible to do easily. I've tried various combinations of
DirectoryMatch
andLocationMatch
in the main configuration files using the newish variable interpolation available in these two directives.Although something like
FallBackResource index.html
is entirely valid configuration, I share Michael Hampton's concern that any use of relative URLs can cause problems. In the case ofFallBackResource index.html
for a particular directory tree, index.html must always be present otherwise you will get the recursion loop you describe for requests whereindex.html
cannot be found.In your case you would need a top level
.htaccess
file withFallBackResource /index.html
, thenFallBackResource /subfoldername/index.html
in each relevant sub folder.A simple script to generate these is probably safest.
The sites about which I originally asked this question are no longer live, but here's what i ended up doing.
I ended up moving these sites to a server running Nginx, where all configuration is done in the config files of the server using a
try_files
directive. It was much easier to manage that way.I believe a work around using
DirectoryIndex
instead ofFallbackResource
might also work. The following will match/a/script/
to the file/some/path/to/a/script/index.py
then/some/path/to/a/script/index.html
then/some/path/to/subfolder/index.py
and finally/some/path/index.py
. This relies uponDirectoryIndex
honouring absolute paths.Repeated calls to
DirectoryIndex
are appended to previous calls. In my caseFallbackResource
was not working and i stumbled upon this as a solution. The above is for CGI/Python files but I believe it will work in your scenario as well.