本文探讨了在sinatra应用中，当处理跨域请求时，`request.referrer`或`request.env[“http_referer”]`为何仅返回来源域（origin）而非完整url的问题。核心原因在于现代浏览器默认采用`strict-origin-when-cross-origin`等更严格的referer策略，这导致在跨域场景下，referer信息会被截断，从而影响开发者获取完整引用url的预期。文章将结合示例代码，详细解释这一现象及其对应用设计的影响。
在开发基于ruby Sinatra框架的Web应用时，我们经常需要获取发起请求的来源URL，即Referer信息。通常，开发者会尝试通过request.referrer或request.env[“HTTP_REFERER”]来获取这一信息。然而，在某些特定场景下，尤其是当应用提供的资源（例如javaScript代码）被部署在不同域名的远程网站引用时，我们可能会发现获取到的Referer并非完整的URL路径，而仅仅是来源网站的协议和域名（即Origin）。这种现象并非Sinatra框架的局限性，而是现代浏览器为了增强用户隐私和安全性，所实施的Referer策略所致。
跨域请求中Referer信息的表现
考虑一个典型的场景：您的Sinatra应用在http://www.server.com上提供一个javascript文件，而这个JavaScript文件被嵌入到另一个域名http://www.remote.com/url-with-test-code.html的网页中。当http://www.remote.com/url-with-test-code.html页面加载并请求http://www.server.com/test时，我们期望在Sinatra应用中通过request.referrer获取到完整的引用URL http://www.remote.com/url-with-test-code.html。然而，实际观测到的结果往往是http://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
当上述Sinatra应用部署在http://www.server.com，并且被以下HTML代码在http://www.remote.com/url-with-test-code.html中引用时：
<html> <body> <script src="http://www.server.com/test"></script> </body> </html>
在Sinatra应用的控制台中，我们可能会看到类似以下的输出：
{: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和:http_referer的值都被截断为https://www.remote.com/，而没有包含完整的路径信息。
根本原因：浏览器Referer策略
这种Referer信息截断的根本原因在于现代浏览器的Referer策略。许多浏览器已经开始默认采用更严格的Referer策略，例如strict-origin-when-cross-origin，而不是旧的默认策略no-referrer-when-downgrade。
- no-referrer-when-downgrade (旧默认)：在同源请求中发送完整的Referer URL。在协议降级（例如从HTTPS到HTTP）时，不发送Referer。其他跨域请求通常会发送完整的Referer URL。
- strict-origin-when-cross-origin (新默认)：
- 对于同源请求，发送完整的Referer URL。
- 对于协议安全级别不变的跨域请求（例如HTTPS到HTTPS），Referer会被截断为仅包含来源的Origin（协议、主机和端口）。
- 对于协议降级的跨域请求（例如HTTPS到HTTP），Referer会被截断为仅包含来源的Origin。
- 在其他一些更严格的场景下（如从HTTPS到HTTP的跨域请求），Referer可能完全不发送（no-referrer）。
这意味着，当一个跨域请求发生时，浏览器为了保护用户隐私，默认情况下不会将完整的路径信息发送给第三方服务器，而是仅仅发送请求的Origin。这种行为有效地防止了通过Referer泄露用户在来源网站上的敏感路径信息。
对应用设计的影响与注意事项
由于浏览器Referer策略的改变，开发者在设计依赖Referer信息的应用时需要注意以下几点：
- 不可完全依赖完整Referer路径：在处理跨域请求时，不应假设服务器端总能获取到完整的Referer路径。如果您的业务逻辑（例如，基于Referer路径进行内容定制或访问控制）需要完整的路径信息，那么这种依赖将不可靠。
- 考虑替代方案：如果确实需要来源页面的完整路径信息，并且该信息对安全性不敏感，可以考虑通过其他方式传递。例如，在请求目标资源时，通过查询参数（Query String）显式地传递来源页面的URL。但这需要来源网站的配合，并且需要注意URL编码和长度限制。
- 理解安全与隐私：浏览器实施这些策略是为了提升用户隐私和安全性。作为开发者，我们应该尊重并理解这些设计选择，避免试图规避它们，而是适应它们。
- Referrer-Policy HTTP头：网站可以通过设置Referrer-Policy HTTP响应头来控制其发出的请求的Referer行为。例如，Referrer-Policy: unsafe-url可以强制发送完整的Referer，但这会带来隐私风险，通常不建议在生产环境中使用。对于被引用的Sinatra应用，它无法控制引用方浏览器发送的Referer策略。
总结
在Sinatra应用中获取request.referrer时，尤其是在处理跨域请求时，Referer信息被截断至仅包含Origin是现代浏览器的普遍行为，而非Sinatra框架的问题。这主要是由浏览器默认采用的strict-origin-when-cross-origin等更严格的Referer策略所导致。开发者在设计需要依赖Referer的应用时，必须充分考虑这一限制，并根据实际需求寻找合适的替代方案，以确保应用的功能性和用户隐私的安全性。理解浏览器Referer策略的细节，有助于我们构建更加健壮和符合现代web安全标准的应用程序。