我使用前端控制器和以下htaccess文件pipe理大量的PHP应用程序：
FallbackResource /index.php 是的，这是整个文件（每个应用程序）！
但是，有些网站位于子文件夹中，因此需要进行以下更改：
FallbackResource /subfolder/index.php
正如你可能猜到的那样， /开头意味着path相对于站点/虚拟主机，这里的path需要相对于目录。
（如果我使用的是mod_rewrite而不是mod_dir ，则需要按照类似的方式将RewriteBase添加到每个子目录中。）
我认为我可以通过这样做来解决这个问题：
FallbackResource index.php # No slash!
但是，当站点的重写包含斜线时，例如，如果应用程序是/store/并且其中的path是products/1234 ，则Apache将查找/store/products/index.php而不是/store/index.php然后在日志中返回一个500与以下消息：
由于可能的configuration错误，请求超过了10个子请求嵌套级别的限制。 如果需要，使用“LimitInternalRecursion”来增加限制。 使用“LogLeveldebugging”来获得回溯。
我会认为FallbackResourcepath是相对于它configuration的.htaccess文件，但它似乎实际上是相对于请求的URL。
有没有办法使FallbackResource按照我的预期行事？
如果这是答案，我可以用它的方式，但如果能做到这一点，pipe理我所拥有的网站会容易得多。 这些网站使用相同的基本代码，不同的主题和数据库连接，现在它的工作方式，现在我必须修改htaccess文件，每次部署新版本的代码（因为它被检查到Git）。 如果我们能够让人们不必每次都记住这个修改，那真是太棒了。
我不认为这是可以做到的。 我在主configuration文件中使用了这两个指令中可用的新variables插值，尝试了DirectoryMatch和LocationMatch各种组合。
虽然像FallBackResource index.html是完全有效的configuration，我分享迈克尔汉普顿的关注任何使用相对URL可能会导致问题。 对于特定目录树的FallBackResource index.html ，index.html必须始终存在，否则您将得到recursion循环，描述其中找不到index.html请求。
在你的情况下，你需要一个与FallBackResource /index.html顶级.htaccess文件，然后在每个相关的子文件夹FallBackResource /subfoldername/index.html 。
一个简单的脚本来生成这些可能是最安全的。
我最初问这个问题的网站已经不存在了，但这是我最终做的。
我结束了移动这些网站到一个运行Nginx的服务器，所有configuration在服务器的configuration文件中使用try_files指令完成。 这样pipe理就容易多了。