【问题标题】:Rewrite from any query string after root to root in .htaccess在 .htaccess 中从 root 之后的任何查询字符串重写为 root
【发布时间】:2017-05-19 02:52:21
【问题描述】:

我需要我的网站将所有带有参数的 URL 重定向到干净的路径:

有:

http://example.com/?id=1

想要:

http://example.com

为什么会这样?我在我的单页网站中使用了分享和喜欢 facebook 按钮,当您来自带有参数的链接时,facebook 按钮不会显示累积的喜欢(它会将其视为新页面)。所以我需要重定向到干净的根路径来显示它们。

【问题讨论】:

  • 我不需要这个参数,我只是用它来填充我的站点地图
  • “我只是用它来填充我的站点地图” - 你到底是什么意思?您不应该在您的 XML 站点地图中包含重定向的 URL?
  • "您不应该在您的 XML 站点地图中包含被重定向的 URL?"你是在问我还是给我建议?
  • 确实是建议,但我也在问......你的评论是什么意思,“我不需要参数,我只是用它来填充我的站点地图”?听起来您在站点地图中包含了参数化的 URL?为什么?您应该只在站点地图中包含规范的 URL。如果您要重定向此 URL,则它不是规范的,因此不应出现在站点地图中。
  • 感谢您的建议,您的回答对我有用。

标签: php facebook .htaccess mod-rewrite


【解决方案1】:

仅从主页中删除任何查询字符串

.htaccess 中,您可以使用 mod_rewrite 重定向所有包含 any 查询字符串的请求。请尝试以下操作:

RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteRule ^$ /? [R,L]

就像问题中给出的示例一样,这只会重定向针对文档根目录/主页的请求。 (即不是表单的 URL:example.com/something?id=1)。

RewriteCond 指令检查查询字符串是否至少包含 1 个字符(即正则表达式 .)。

通过在 substitution 字符串(尾随 ?)中附加一个空查询字符串来“删除”查询字符串。 ? 不在重定向响应中。

如果您要求此重定向是永久的,则将 R 标志更改为 R=301,否则它将默认为 302(临时)重定向。


更通用的,任何 URL路径

如果您想要一个更通用的解决方案来从 any URL 路径中删除查询字符串,那么您可以将 RewriteRule 指令更改为以下内容(保持与上述相同的 RewriteCond 指令) :

RewriteRule ^ %{REQUEST_URI} [QSD,R=302,L]

现在,对example.com/anything?something 的请求将被重定向到example.com/anything

这还使用 QSD(查询字符串丢弃)标志 (Apache 2.4) 来删除查询字符串,而不是像 Apache 2.2 和更早版本(第一个示例)所要求的那样附加空查询字符串。


边缘情况 - 空查询字符串

对上述指令的一个小警告是,不会删除存在的但其他情况下为 empty 的查询字符串(例如,带有尾随 ? 的 URL 路径)。例如,给定一个example.com/? 形式的请求,那么结尾的? 将保留,因为查询字符串是严格“空”的(并且上述条件 不匹配)。

如果您还特别想缓存这种边缘情况,那么您可以在RewriteCond 指令中匹配THE_REQUEST。例如:

RewriteCond %{THE_REQUEST} \?
RewriteRule ^ %{REQUEST_URI} [QSD,R=302,L]

条件只检查 URL 中任意位置的未编码 ?

【讨论】:

【解决方案2】:

你放了一个 PHP 标签,所以这是一个 PHP 解决方案。

在您的index.php 中,您可以检查是否有任何 GET 变量并重定向回该站点。这需要在页面发送任何输出之前进行,因此应该尽可能靠近页面顶部。

if (count($_GET) > 0) {
    header("Location: " . $_SERVER['PHP_SELF']);
    die(); // Very important to prevent the rest of the page from executing anyway
}

如果您想确保隐藏脚本的名称,也可以使用 header("Location: /");

【讨论】:

  • 你不应该在这样的脚本中使用PHP_SELF unsanitized。除了暴露脚本的名称(如您所建议的那样)之外,您还向潜在的 XSS 漏洞敞开了大门。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-12-10
  • 2011-04-06
  • 1970-01-01
  • 2010-11-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多