【问题标题】:Using mod_write for cleanurls with Lets Encrypt通过 Let's Encrypt 使用 mod_rewrite 获取干净的 url
【发布时间】:2016-10-06 23:23:25
【问题描述】:

我在 Ubuntu 14.04 上运行 Apache 的服务器上启用了 Let's Encrypt,并使用自动选项将所有 http 请求重定向到 https。这工作正常。

但是,我现在想使用 mod_rewrite 在我的网站上使用 cleanurls - 我需要做的就是从所有文件名中删除 .php 扩展名。 (例如https://example.com/contact 路由到https://example.com/contact.php

我已尝试将以下重写规则添加到 .htaccess 文件中:

RewriteEngine on 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php

此配置在我的本地主机设置(没有 SSL)上运行良好,但在运行 Lets Encrypt 的实例上不起作用。

我已经通过添加此规则来测试 .htaccess 是否正常工作,该规则按预期工作(将所有 www 请求重定向到根域)

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

我怀疑 Lets Encrypt 自动设置选项和我的 mod_rewrite 规则之间可能存在一些冲突,但我不知道如何让它们一起工作。

任何帮助将不胜感激。

【问题讨论】:

  • “将所有http请求重定向到https的自动选项”实际上是做什么的?重定向是如何实现的?次要的点(这实际上不会改变任何东西),但无需转义 RewriteCond TestString 中的点 - 这是一个普通字符串,而不是正则表达式。
  • 据我所知,它将以下内容添加到 sitename.conf Apache 虚拟主机文件 RewriteEngine on RewriteCond %{SERVER_NAME} =sitename [OR] RewriteCond %{SERVER_NAME} =www.sitename RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
  • auto 选项还创建了第二个名为“sitename-le-ssl.conf”的 apache conf 文件
  • 我检查了 REQUEST_FILENAME 返回的内容 - 它是文件名的路径(例如 [REQUEST_FILENAME] => /var/www/sitename/public_html/output.php) - 我得到了相同的结果结果在 localhost 上运行,只是使用不同的文件路径。
  • 我还按照您的建议启用了详细日志记录,并且可以看到与重写相关的错误。例如RewriteCond: input='/var/www/sitename/public_html/output.php.php' pattern='-f' => not-matched .php 文件扩展名似乎重复了 - 这可能是问题的根源吗?

标签: apache .htaccess mod-rewrite encryption


【解决方案1】:

.htaccess 中禁用MultiViews

Options -MultiViews

MultiViews(mod_negotiation 的一部分)可能会导致冲突。这与您尝试使用 mod_rewrite 实现的功能非常相似。启用 MultiViews(可能在服务器配置中启用,尽管默认为 disabled),对/filename 的请求将导致 Apache 寻找匹配的文件 (通过单步执行该目录中的文件(主要是尝试 basename 匹配的各种扩展名)来返回适当的 mime 类型)。

我检查了 REQUEST_FILENAME 返回的内容 - 它是文件名的路径(例如 [REQUEST_FILENAME] => /var/www/sitename/public_html/output.php)

是的,这就是问题所在。 MultiViews 已经在 mod_rewrite 能够完成它之前“修复”了 URL(outputoutput.php)。

【讨论】:

  • 问题已解决,谢谢。 MultiViews(我不知道)大概也解释了为什么“cleanurls”似乎已经适用于 .html 文件(没有任何 mod_rewrite 规则)。虽然 MultiViews 可以使用一个文件扩展名而不是另一个文件扩展名,但这看起来确实很奇怪。
  • 是的,MultiViews 可以解释为什么“干净的”.html URL 神奇地 可以正常工作。与.php URL 的冲突(在启用 MultiViews 的情况下最终破坏了您的网站 - 我假设是 404(?))可能​​是“其他地方”。添加 .php 扩展名的 mod_rewrite 指令(在您的问题中)将失败(因为前面的文件检查 condition 会失败)。我假设您的 www 到非 www 规范重定向会“神奇地”重定向到 .php URL?
猜你喜欢
  • 1970-01-01
  • 2010-12-06
  • 2012-04-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-24
  • 2016-02-25
  • 1970-01-01
相关资源
最近更新 更多