在进行 301 重定向时，谁是 UserAgent？答案

【问题标题】：When doing a 301 redirect, who's the UserAgent?在进行 301 重定向时，谁是 UserAgent？
【发布时间】：2019-01-30 12:47:42
【问题描述】：

'HTTP_REFERER' 引用该页面的地址（如果有）用户代理到当前页面。 这是由用户代理设置的。并非全部用户代理会设置这个，有些提供修改的能力 HTTP_REFERER 作为一个特性。简而言之，它不能真正被信任。

我的问题是，如果重定向发生在服务器级别，谁会被视为 UserAgent？以及如何确保通过 301 发送推荐人信息？

例如我有页面 mywebsite1.com/page，我 301 重定向到 mywebsite2.com/page 现在当它转到我的 mywebsite2.com/page 时，我看不到任何推荐人信息，我想知道是谁设置了这些信息！

【问题讨论】：

网络浏览器（通常）。
用户代理在大多数情况下是浏览器。浏览器可以随意发送或省略referer header。
试试怎么样？
假设您使用的是 cURL。类似于User-Agent: curl/7.37.0。只需转储标题，您就会确切地看到其中的内容。
澄清一下，重定向不会发生在服务器级别。服务器发送一个重定向 response 要求用户代理（无论访问该页面的人）遵循该重定向。用户代理可能跟随它，并且它也可能在请求新页面时发送一个引用标头。

【解决方案1】：

“用户代理”是向 HTTP 服务器发送 HTTP 请求的客户端。在大多数情况下，用户代理是一个网络浏览器，但该术语更笼统地包括自动化脚本之类的东西。

您问题中的主要误解是重定向不会“发生在服务器级别”。会发生什么：

“referer”标头（拼写错误是历史性的，现在正式“正确”）只是用户代理随每个请求发送的信息的一部分。（重要的是，就像请求中的所有内容一样，出于任何安全目的都不能信任它，因为有人可以编写具有他们想要的任何值的请求。）

RFC section on the Referer header 没有非常详细地指定它的行为，我找不到任何关于在重定向响应后应该如何填充它的参考。因此，不同的用户代理的行为可能不同，您需要在不同的浏览器中进行测试才能确定。

【讨论】：

【解决方案2】：

仅依靠引荐来源网址根本不可靠，因为浏览器可能会忽略提供，具体取决于用户的隐私设置、已安装的插件甚至浏览器设置。

检测来自您重定向的用户的最佳方法是将他们重定向到类似mywebsite2.com/page?redirected_from=mywebsite1 的位置，然后在位于mywebsite2.com 的页面上查找该查询字符串。

希望这是有道理的。

【讨论】：

【解决方案3】：

用户代理是发出 HTTP 请求的任何实体，它可能是浏览器、由充当客户端并发出请求的服务器应用程序使用的内部库、将请求转发到其他地址或服务的代理服务器。

不保证引荐来源网址将被转发到目标服务器。例如，在代理中，您必须指示它将引荐来源标头转发到目标服务器（通常在配置级别）。以类似的方式，您应该检查负责处理重定向的人是否将引用标头转发到以下请求（重定向的目标）。

如果您使用 Guzzle 来处理重定向，那么您应该查看 Guzzle docs 以自动将标头添加到请求中。如果 Apache 负责处理重定向，您应该干预以在网络服务器配置中设置标头，在此 SO answer 中，您可以找到一种在重定向时以编程方式设置标头的方法。

【讨论】：

关于在 Apache 中添加标头的链接答案是关于将标头添加到 response，而这个问题是关于 request 中的标头。除了用作代理时，Apache 不充当 客户端，因此不会创建 HTTP 请求。
我试图回答这部分问题：“我如何确保通过 301 发送推荐人信息？”。我看到了 PHP 和 Laravel 标签，所以我假设了最常见的环境（Guzzle 作为 PHP HTTPClient 和 Apache 作为网络服务器）。
使用 Guzzle 发出的请求将具有库设置的任何标头，或者 PHP 脚本告诉它设置的标头；在 Apache 配置文件中添加 Header 行将对此没有任何影响。（想象一下，如果它这样做了：这意味着该 PHP 脚本发出的每个请求都将包含相同的标头；这不会很有用。）