Sinatra 应用中获取完整引用 URL 的策略与挑战

在 sinatra 应用中，尝试获取跨域请求的完整引用 url 时，`request.referrer` 或 `request.env["http_referer"]` 常常只返回源站而非完整路径。这并非 sinatra 的问题，而是现代浏览器默认采用 `strict-origin-when-cross-origin` 等更严格的 referrer policy 所致，旨在增强用户隐私保护，导致跨域时 referer 信息被截断。

跨域引用 URL 获取的困境

在开发 Web 应用时，尤其当应用提供 JavaScript 代码供外部网站引用时，我们经常需要获取调用方（即引用方）的完整 URL。例如，一个 Sinatra 应用托管了一个 JavaScript 资源，被 http://www.remote.com/url-with-test-code.html 页面通过 引用。开发者可能期望在 Sinatra 后端通过 request.referrer 或 request.env["HTTP_REFERER"] 获取到完整的引用页面 URL，即 http://www.remote.com/url-with-test-code.html。

然而，实际观测到的结果往往是 referrer 键仅包含引用页面的协议和域名，例如 https://www.remote.com/，而缺少了具体的路径信息。以下是一个简单的 Sinatra 测试代码示例，用于演示此现象：

require 'sinatra'

get %r{/test} do
    debug = {
        :referrer => request.referrer,
        :http_referer => request.env["HTTP_REFERER"],
        :path_info => request.path_info,
        :query_string => request.query_string,
        :host => request.host,
        :url => request.url,
        :path => request.path
    }
    STDERR.puts debug.inspect
    erb "test"
end

当 http://www.server.com/test 被 http://www.remote.com/url-with-test-code.html 引用时，服务器端日志可能会显示类似以下内容：

{:referrer=>"https://www.remote.com/", :http_referer=>"https://www.remote.com/", :path_info=>"/test", :query_string=>"", :host=>"www.server.com", :url=>"https://www.server.com/test", :path=>"/test"}

这表明 referrer 字段被截断，未能提供完整的引用路径。

浏览器 Referrer Policy 详解

导致上述现象的根本原因在于现代浏览器的 Referrer Policy（引用者策略）。为了增强用户隐私保护，许多浏览器已经将默认的 Referrer Policy 从旧的 no-referrer-when-downgrade 更改为更严格的 strict-origin-when-cross-origin。

百度MCP广场

探索海量可用的MCP Servers

下载

理解这些策略至关重要：

• no-referrer-when-downgrade (旧默认):
  • 当协议安全等级保持不变（HTTP 到 HTTP，HTTPS 到 HTTPS）或从 HTTPS 降级到 HTTP 时，发送完整的 URL 作为 Referer。
  • 当从 HTTPS 降级到 HTTP 时，Referer 不会被发送。
  • 在跨域请求中，通常会发送完整的 URL。
• strict-origin-when-cross-origin (新默认):
  • 当同源请求时，发送完整的 URL。
  • 当进行跨域请求时，Referer 头部只包含源站（协议、域名和端口），不包含路径和查询参数。
  • 当协议安全等级从 HTTPS 降级到 HTTP 时，Referer 不会被发送。

这意味着，当您的 Sinatra 应用（http://www.server.com）被另一个域名（http://www.remote.com）的页面引用时，由于这是一个跨域请求，并且现代浏览器默认遵循 strict-origin-when-cross-origin 策略，Referer 头部会被浏览器自动截断，只发送源站信息。

此外，还有其他 Referrer Policy 选项，例如：

• no-referrer: 任何情况下都不发送 Referer 头部。
• same-origin: 仅在同源请求中发送 Referer 头部，跨域请求不发送。
• origin: 无论同源还是跨域，Referer 头部都只包含源站。
• unsafe-url: 总是发送完整的 URL，即使是从 HTTPS 降级到 HTTP，这被认为是不安全的。

注意事项与总结

1. 浏览器行为，非 Sinatra 限制: request.referrer 获取到的值直接来源于 HTTP 请求头中的 Referer 字段，而这个字段的内容是由发起请求的浏览器根据其 Referrer Policy 决定的。因此，这不是 Sinatra 框架的限制，而是浏览器为了用户隐私和安全而实施的策略。
2. 无法强制获取: 作为服务器端，您无法强制浏览器发送完整的 Referer URL，因为这是客户端（浏览器）的安全策略。
3. 影响: 这种截断会影响依赖完整 Referer URL 进行统计、日志记录或个性化内容生成的功能。例如，如果您的 JavaScript 代码需要根据调用它的具体页面路径来调整行为，仅依靠 request.referrer 将无法实现。
4. 替代方案: 如果确实需要获取引用页面的完整路径，您可能需要考虑其他客户端协作方式：
   • 客户端传递: 在引用您的 JavaScript 代码的页面上，可以通过 JavaScript 获取 window.location.href，然后将其作为查询参数或 POST 数据传递给您的 Sinatra 服务。
   • 用户授权: 在某些特定应用场景下，如果用户明确授权，可以通过其他机制（如 OAuth）获取更详细的客户端信息。

综上所述，当在 Sinatra 应用中发现 request.referrer 无法获取完整的跨域引用 URL 时，应理解这是现代浏览器 Referrer Policy 的预期行为。开发者需要适应这一变化，并根据实际需求考虑采用其他客户端辅助的解决方案，而不是期望服务器端能直接绕过浏览器的安全策略。