mod_rewrite:通过%{HTTP_HOST}将子域重写到目录时出错 [英] mod_rewrite: Error whilst rewriting subdomain to directory via %{HTTP_HOST}

查看:62
本文介绍了mod_rewrite:通过%{HTTP_HOST}将子域重写到目录时出错的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

与Apache的mod_rewrite相比,我遇到的麻烦比我想象的要多.我已经在网站上发布了一个问题 问题,并且已经弄清了,但是我仍然遇到错误,无法看到任何逻辑错误 配置.任何帮助将不胜感激!

I am having more trouble than I thought when it comes to Apache's mod_rewrite. I've already posted one question on the matter, and that has been clarified, but I continue to get errors where I cannot see any logical fault in the configuration. Any help would be greatly appreciated!

我正在使用的.htaccess如下:

# Begin Rewrite Module for http://*.example.com/
# ==============================================
<IfModule mod_rewrite.c>

    # Turn the rewrite engine on and set the base path.
    RewriteEngine On
    RewriteBase /

    # Map subdomains to their respective directories.
    RewriteCond %{HTTP_HOST} ^([^\.]+)\.example\.com$ [NC]
    RewriteRule ^(.*)$ public_subdomains/%1/$1 [L]

</IfModule>

由于内部重定向过多,此操作不起作用,导致出现500 Internal Server Error-这是它的调试日志:

This doesn't work because of too many internal redirects, resulting in a 500 Internal Server Error - here is the debug log for it:

[Fri Feb 15 16:49:30.318509 2013] [core:error] [pid 2316:tid 1708] [client 127.0.0.1:9141] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3502): [client 127.0.0.1:9141] AH00121: r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /public_subdomains/sub1/index.php
[Fri Feb 15 16:49:30.318509 2013] [core:debug] [pid 2316:tid 1708] core.c(3508): [client 127.0.0.1:9141] AH00122: redirected from r->uri = /

通过将RewriteRule上的[END]标志替换为[L]标志,我找到了一种解决方案,它可以完美地将请求URI精确映射到子域目录中的相应文件.

I found a sort-of solution for it, by replacing the [L] flag for the [END] flag on the RewriteRule, and it works perfectly mapping the request URI exactly to the corresponding file in the sub-domain directory.

不幸的是,它工作得太完美了.对subdomain.example.com/folder/的调用在不应该考虑DirectoryIndex的情况下,将其内部重写为example.com/public_subdomains/subdomain/folder/,此时它应重写为example.com/public_subdomains/subdomain/folder/index.php(假定index.php设置为DirectoryIndex).

Unfortunately it works too perfectly. A call to subdomain.example.com/folder/ interally rewrites to example.com/public_subdomains/subdomain/folder/ without taking into account the DirectoryIndex, when it should rewrite as example.com/public_subdomains/subdomain/folder/index.php (assuming that index.php is set as the DirectoryIndex).

如果有人可以帮助我阐明这一点,我将永远感激不已!

If anyone can help me shed light on this, I would be eternally grateful!

推荐答案

好吧,这是一个逻辑错误.让我参考文档:

Well, there is a logic error all right. Let me refer you to the wonderful control flow diagram from the docs:

您会看到,内部重定向也是一个请求,因此任何和所有重写规则都会再次对其进行处理.因此,假设用户请求了某事.example.com/x:RewriteRule Macthes,实现了RewriteCond,因此进行了内部重定向到public_subdomains/something/x.新的请求是对something.example.com/public_subdomains/something/x:RewriteRule匹配,RewriteCond已实现...在那里,您将无休止地循环.

You see, an internal redirect is a request too, so it's once again processed by any and all rewrite rules. So, suppose a user requests something.example.com/x: RewriteRule macthes, RewriteCond is fulfilled, so an internal redirect to public_subdomains/something/x is made. The new request is to something.example.com/public_subdomains/something/x: RewriteRule matches, RewriteCond is fulfilled... And there you have the endless loop.

[L]标志仅停止处理当前请求:无论如何,该请求将在第二遍处理中处理. [END]标志确实停止了循环,但是这是蛮力的,因为您已经注意到它有副作用,因此最好合并一个停止递归的条件.像这样:

The [L] flag only stops processing of the current request: the request will be processed in the second pass anyway. The [END] flag does stop the loop, but it's a brute-force thing, as you've noticed it has side effects, so it'd be better to incorporate a condition that stops the recursion. Something like this:

RewriteCond %{HTTP_HOST} ^([^\.]+)\.example\.com$ [NC]
RewriteCond %{REQUEST_URI} !^/public_subdomains/%1
RewriteRule ^(.*)$ public_subdomains/%1/$1 [L]

添加的RewriteCond将检查请求的uri是否已经以"public_subdomains/something"开头.

The added RewriteCond would check to see if the requested uri already begins with "public_subdomains/something".

它未经测试,因此可能有问题,但这是基本思想.

It's untested, so may have issues, but this is the basic idea.

这篇关于mod_rewrite:通过%{HTTP_HOST}将子域重写到目录时出错的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆