重定向，如果第一次尝试失败后备文件 [英] Redirect to fallback file if first attempt fails

问题描述

我已经在我的的.htaccess ：

RewriteRule ^images/([^/\.]+)/(.+)$ themes/current/images/$1/$2 [NC]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^images/([^/\.]+)/(.+)$ modules/$1/images/$2 [L,NC]

的想法是，将执行以下操作：

The idea is that it does the following:

// Rewrite this...
images/calendar/gear.png

// ... to this
themes/current/images/calendar/gear.png

// HOWEVER, if that rewritten path doesn't exist, rewrite the original URL to this:
modules/calendar/images/gear.png

这改变这里唯一的事情是日历和 gear.png ，其中第一项可以是其他任何一个字，而后者的文件名（可能路径）添加到图像文件中。

The only things that change here are calendar and gear.png, the first of which could be any other single word and the latter the file name (possibly with path) to an image file.

我可以重写原始URL的第一重写如图所示的例子就好了，但我不能做的就是让我的.htaccess来提供该文件从另一个，回退的位置，如果在第一个位置404。我下了不使用IM pression [L] 在我的第一个重写规则将重写网址的RewriteCond 。

I can rewrite the original URL to the first rewrite as shown in the example just fine, but what I cannot do is get my .htaccess to serve up the file from the other, fallback location if the first location 404s. I was under the impression that not using [L] in my first RewriteRule would rewrite the URL for RewriteCond.

我遇到的问题是，而不是服务于后备文件，浏览器只显示404到第重写路径（主题/电流/日历/ gear.png ），而不是回落至模块/日历/ gear.png 。我究竟做错了什么？

The problem I'm having is that instead of serving the fallback file, the browser just shows a 404 to the first rewritten path (themes/current/calendar/gear.png), instead of falling back to modules/calendar/gear.png. What am I doing wrong?

请注意，我的正则表达式是不完美的，但后来我可以细化。现在，我就用自己的重写逻辑本身。

Please note that my regex isn't perfect, but I can refine that later. Right now I'm concerning myself with the rewrite logic itself.

推荐答案

Fallthrough规则是充满了错误。我通常的建议是不是比其他替换字符串的任何规则 - 应该触发内部重定向重新启动的.htaccess 解析。这就避免了子请求和URI_PATH错误。

Fallthrough rules are fraught with bugs. My general recommendation is than any rule with a replacement string other than - should trigger an internal redirect to restart the .htaccess parse. This avoids the subrequest and URI_PATH bugs.

接下来，一旦你去404，又在我的经验，这是不可恢复的。我有一个片段做类似的东西您正在尝试做的：

Next once you go to 404, again in my experience this is unrecoverable. I have a fragment which does something similar to what you are trying to do:

# For HTML cacheable blog URIs (a GET to a specific list, with no query params, 
# guest user and the HTML cache file exists) then use it instead of executing PHP

RewriteCond %{HTTP_COOKIE} !blog_user
RewriteCond %{REQUEST_METHOD}%{QUERY_STRING}  =GET               [NC]
RewriteCond %{ENV:DOCUMENT_ROOT_REAL}/blog/html_cache/$1.html -f
RewriteRule ^(article-\d+|index|sitemap.xml|search-\w+|rss-[0-9a-z]*)$ \
            blog/html_cache/$1.html                              [L,E=END:1]

请注意，我做的测试条件的文件系统空间，而不是URI（位置）的空间。因此，这会在你的情况映射到

Note that I do the conditional test in filesystem space and not URI (Location) space. So this would map in your case to

RewriteCond %{DOCUMENT_ROOT}/themes/current/images/$1/$2l -f
RewriteRule ^images/(.+?)/(.+)$ themes/current/images/$1/$2 [L]

虽然做的phpinfo（）来检查，看看您的托管服务提供商使用一种替代为 DOCUMENT_ROOT 如果它是一个共享的主机，提供如替代环境变量，矿用 DOCUMENT_ROOT_REAL

Though do a phpinfo() to check to see if your hosting provider uses an alternative to DOCUMENT_ROOT if it is a shared hosting offering e.g an alternative environment variable as mine uses DOCUMENT_ROOT_REAL.

第二条规则将有所回升第二处理过去的内部重定向后。

The second rule will be picked up on the second processing past after the internal redirect.

这篇关于重定向，如果第一次尝试失败后备文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！