本文探讨了在 sinatra 应用中尝试获取完整引荐来源 url 时遇到的常见问题，即 `request.referrer` 仅返回协议和域名。核心原因在于现代浏览器默认采用更严格的引荐来源策略（如 `strict-origin-when-cross-origin`），这导致跨域请求时引荐来源 url 被截断。文章将详细解释这一机制，并通过示例代码展示问题，并提供理解和应对策略。
在构建 Web 应用程序时，有时我们需要了解用户是从哪个完整的 URL 跳转或引用到当前页面的。特别是在提供 JavaScript 代码给外部网站调用时，获取调用方网站的完整 URL 对于分析、日志记录或根据来源调整响应内容至关重要。然而，开发者在使用 Sinatra 框架的 request.referrer 或 request.env["HTTP_REFERER"] 属性时，可能会发现它们仅返回了引荐来源的协议和域名，而非完整的路径信息，这与预期行为不符。
问题场景复现
假设我们有一个 Sinatra 应用，其目标是识别调用其提供的 JavaScript 代码的远程网站的完整 URL。以下是一个简化的 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" # 假设存在一个 test.erb 模板
end如果这个 Sinatra 应用部署在 http://www.server.com，并且有一个远程网站 http://www.remote.com/url-with-test-code.html 包含如下 HTML 代码，通过
当 http://www.remote.com/url-with-test-code.html 页面加载并请求 http://www.server.com/test 时，我们期望在 Sinatra 应用的日志中看到 :referrer 键的值为 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"}从上述输出可以看出，request.referrer 和 request.env["HTTP_REFERER"] 都被截断为仅包含协议和域名 (https://www.remote.com/)，而丢失了具体的路径信息 (url-with-test-code.html)。
根源分析：浏览器引荐来源策略
这种现象并非 Sinatra 或 Ruby 的问题，而是现代浏览器为了增强用户隐私和安全性而实施的引荐来源（Referrer）策略所致。许多浏览器已经将默认的引荐来源策略从旧的 no-referrer-when-downgrade 更改为更严格的 strict-origin-when-cross-origin。
- no-referrer-when-downgrade (旧默认值): 在协议降级（例如 HTTPS 到 HTTP）时，不发送 Referer 头部。其他情况下，会发送完整的 URL。
-
strict-origin-when-cross-origin (新默认值):
- 在同源请求中，发送完整的 URL 作为 Referer。
- 在跨源请求中，仅发送源（协议、主机和端口）作为 Referer。这意味着路径和查询参数等信息会被移除。
- 在协议降级时，不发送 Referer。
当 http://www.remote.com 请求 http://www.server.com 上的资源时，这是一个典型的跨源请求。根据 strict-origin-when-cross-origin 策略，浏览器只会发送 http://www.remote.com/ 作为引荐来源，从而导致服务器端获取到的 Referer URL 被截断。在某些更严格的策略下（如 no-referrer），甚至可能完全不发送 Referer 头部。
应对策略与注意事项
由于这是浏览器级别的安全和隐私特性，服务器端无法强制浏览器发送完整的跨域 Referer URL。因此，我们不能直接依赖 request.referrer 来获取完整的远程网站路径。
理解与适应： 接受这一事实是关键。如果您的应用逻辑需要完整的来源 URL，并且该来源是跨域的，那么您可能需要重新评估您的设计或寻找替代方案。
-
客户端协作（如果可能）： 如果您对远程网站的 HTML 内容有控制权，或者可以与远程网站的开发者协作，可以考虑通过客户端 JavaScript 将完整的 window.location.href 作为查询参数传递给您的脚本。例如：
在 Sinatra 应用中，您就可以通过 request.params["referrer_url"] 获取到这个值。但这需要远程网站的主动配合。
仅依赖来源信息： 如果您的需求只是识别请求的来源域名，那么当前 request.referrer 返回的截断信息已经足够。例如，判断请求是否来自白名单域名，或者进行基于域名的统计。
服务器端日志分析： 某些情况下，如果您有能力访问请求发起方的服务器日志（例如通过 CDN 或其他代理），这些日志可能包含更详细的请求信息，但这超出了直接通过 request.referrer 获取的范畴。
总结
在 Sinatra 或任何其他 Web 框架中，当处理跨域请求时，期望通过 request.referrer 获取完整的引荐来源 URL 是不现实的。这是由现代浏览器默认的更严格的引荐来源策略 (strict-origin-when-cross-origin) 决定的，旨在保护用户隐私。开发者应理解这一机制，并根据实际需求调整应用程序的设计，例如通过客户端主动传递信息或仅依赖可用的来源域名信息。直接从服务器端获取完整的跨域引荐来源 URL 几乎是不可能的任务。
