☰

302 重定向对于最终目的地是否可见？

tag-icon • tag-icon http redirection
302 重定向对于最终目的地是否可见？

请考虑以下情形：

https://foo和都https://bar将用户的 Web 浏览器重定向到https://destination使用Location带有 HTTP 响应代码的标头302

我的问题是，服务器是否可以https://destination识别流量是从哪个服务器重定向的？

答案1

我想说，这个问题无法明确回答，因为它取决于网站的具体配置和使用的用户代理（浏览器）。长话短说：如果destination所有者不控制foo，bar那么可能会非常困难，如果控制，开发人员很容易实现。

首先，你需要指定如何服务器destination需要识别请求来源。以下是几种方法（非封闭列表）：

  • 按Referer标题；
  • 通过GET/POST参数；
  • 通过 cookies；
  • 通过一些更复杂和不清楚的逻辑。

引荐来源

对于Referer，答案与这个问题，只需较新的 HTTP RFC 文档咨询。

长话短说：

  • 如果foo和bar 明确地设置Referer标题（如这里) — 它可能会出现在请求中destination（但这取决于用户代理）；
  • 如果通过安全连接检索初始页面，并通过不安全连接检索重定向页面 - 用户代理不得包含标头；
  • 如果没有明确指定，则由用户代理自行决定。许多浏览器可能不包含标头，但这并不能保证，并且可能会因版本而异，因为 RFC 并未强制要求此处的行为。

GET/POST 参数

如果所有服务器的所有者都一致，他们可以使用 GET/POST 参数将原始信息传递给destination，如中所述另一个线程。

饼干

如果所有服务器的所有者都一致，他们可以使用 cookie 甚至某种用户跟踪机制（如 Google Analytics）——可能有办法利用这些知识来了解该用户来自哪里。

其他选择

如果destination所有者无法访问或影响foo和bar服务器，他可能仍然能够通过仔细检查所有标头和字段从请求中推断出一些数据 - 有很小的可能性和foo会bar设置一些不同的标头，或将用户重定向到略有不同的页面，或表现出一些其他允许追踪来源的行为。但这当然不是一个可靠的解决方案，即使可能的话。

相关内容