【问题标题】:.htaccess subdomain to folder.htaccess 子域到文件夹
【发布时间】:2010-08-24 13:47:10
【问题描述】:

我最近对我网站的文件夹结构进行了一些小改动,现在我的一个重写器似乎坏了。

过去,我在 public_html 中有一个 /mydomain.com/ 文件夹,其中设置了一个 wiki。在同一个文件夹中还有一些我用于子域访问的文件夹,例如成员和文件。

旧设置:

#www to main website
RewriteCond %{HTTP_HOST} ^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]

相当简单,当我输入 files.mydomain.com/myfile.zip 时,它没有任何问题。

最近我在我的wiki上安装了几种语言(这实际上与问题无关,只是为了说明情况)并制定了以下规则:

#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es).mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/misc/%1/$1 [L]

显然,在 mydomain.com/www/、mydomain.com/es/ 等中设置了不同语言的 wiki。这非常有效。 问题在于第二部分,即子文件夹。在同一个 mydomain.com/ 文件夹中,我创建了一个 misc/ 文件夹来存储所有 misc 内容(包括子域文件夹)。我认为只需在路径中添加 /misc/ (就像我在第一条规则中添加了语言文件夹名称)就可以让它工作..但它给了我一个 500 错误。 旧设置和新设置在任何可能与第二条规则冲突的文件夹中都没有任何 .htaccess 行。

谁能发现错误,或告诉我如何系统地检查此设置是否存在错误?

【问题讨论】:

  • 我希望您的旧设置和新设置都会生成 500 错误。您的旧设置是否在关闭 mod_rewrite 的子目录中包含 .htaccess 文件?
  • 嗯,不,据我所知,只有一些特定于 mediawiki 的规则(仅当 /wiki/ 包含在 URI 中时才适用)。为什么会出现错误?
  • 您的规则将导致无限重定向循环。在您的 Apache 错误日志中,它可能会说“由于可能的配置错误,请求超出了 10 个内部重定向的限制”?
  • 然而第一条规则并没有给出错误。你建议如何尝试解决这个问题?

标签: .htaccess mod-rewrite


【解决方案1】:

我认为防止发生重定向循环的最简单方法是检查您是否已经将 URL 重写为您打算去的地方。我们可以通过几种不同的方式做到这一点;例如,如果您知道该文件在重写后将存在,则可以以%{REQUEST_FILENAME} !-f 为条件。

在您的情况下,由于您将所有内容都重写到 /public_html 目录中的公共文件夹中,因此我们可以检查是否已经完成:

#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es)\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/%1/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*)\.example\.com$
RewriteCond %{HTTP_HOST} !^www\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/misc/%1/$1 [L]

诚然,我不确定您为什么现在遇到问题,但以前没有。我在我的测试服务器上运行了您的原始规则集,但由于内部重定向过多而导致内部服务器错误,因此我们的设置肯定存在差异。无论如何,希望这会让事情对你有用。

【讨论】:

  • 我会在几秒钟内试试这个,但是 /example.com/ 子文件夹在任何时候都不应该在 uri 中.. rewriterule 中没有 [R] 标志,所以它应该保留隐。我可以尝试检查文件是否存在,但如果我输入了不正确的文件名,这意味着我仍然会收到服务器错误,而不是常规的 404。此外,这应该意味着第一条规则也不起作用,但它做。错误在于两个规则之间的差异,但我无法弄清楚有什么不同。我已经检查了第一条规则的 htaccess 文件,但我也找不到任何东西。
  • @Litso - 我忘了解释这一点,但是在您执行初始重写以包含新的内部请求路径后,%{REQUEST_URI} 的值在内部发生了更改,即使此转换对用户,这就是我们可以执行该检查的原因。
  • 谢谢,我不知道最后一部分。毕竟,在 uri 中检查 /example.com/ 似乎确实有效,我应该只是听过 :P 至少我今天学到了一些东西。
  • @Litso - 啊哈!我想我也弄清楚了为什么设置之间会出现问题,尽管我的猜测很多。以前,当您只有一个 wiki 时,/example.com 中是否有一个单独的 .htaccess wiki 文件?如果是这样,并且假设您在安装新语言时将 .htaccess 文件移动到相应的语言目录,在您的原始设置中,对您的文件的请求与 wiki 的 .htaccess 文件位于相同的请求路径,并且规则从您的/public_html 目录中被忽略(规则集不与父目录中的规则集)...
  • 我认为情况并非如此,但你说得很好。也许这确实是发生了什么......至少现在一切正常!非常感谢:)
猜你喜欢
  • 1970-01-01
  • 2011-02-20
  • 1970-01-01
  • 2021-08-14
  • 2012-05-19
  • 2012-09-14
  • 2019-07-10
  • 1970-01-01
  • 2016-01-18
相关资源
最近更新 更多