浏览器未显示X-Forwarded-For标头的原因

Question

注意:请阅读完整的问题

我试图理解为什么每次请求页面时浏览器都没有向我显示任何X-Forwarded-For标头

BTW这里是我的请求标题看起来像

Request URL:http://localhost:3000/users/sign_in
Request Method:GET
Status Code:304 Not Modified

请求标题:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:undefined=0; poasterapp=s%3A4faaa6b1723e7c6fbd949083532c52598652547b.sNX%2BKOEed2TEQkQN7I7K5lgpoHMRpwerKFvUegMnTVI; _minerva_session=BAh7CUkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiCmZsYXNoBjsARm86JUFjdGlvbkRpc3BhdGNoOjpGbGFzaDo6Rmxhc2hIYXNoCToKQHVzZWRvOghTZXQGOgpAaGFzaHsGOgphbGVydFQ6DEBjbG9zZWRGOg1AZmxhc2hlc3sGOwpJIgAGOwBUOglAbm93MEkiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--6bd89ce9d29e9bdcf56573f9a153dc663a8fe755
Host:localhost:3000
If-None-Match:"785d34e3998360353567fc710af123fb"
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.102 Safari/537.36

响应标题(不需要但仍然)

Cache-Control:max-age=0, private, must-revalidate
Connection:close
ETag:"785d34e3998360353567fc710af123fb"
Server:thin 1.5.0 codename Knife
Set-Cookie:_minerva_session=BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--dfb3ce9f5c97463cfcd0229a133654e6cc606d98; path=/; HttpOnly
X-Request-Id:41a6f3062dc8bc36b7b3eae71dc5075d
X-Runtime:89.238257
X-UA-Compatible:IE=Edge

现在如上所述,我在请求标头中看不到任何 X-Forwarded-For

阅读X-Forwarded-For的维基页面让我觉得,它是由缓存服务器完成的(在我的情况下,我相信是我的ISP提供商)so am I safe to believe that the **X-Forwarded-For** headers is something that is added at the caching server side (ISP provider)

如果是的话他们就是这个让我烦恼的话就是这样

为什么？X-Forwarded-For对于在我的机器上本地运行的服务器并且我通过浏览器访问它们,它们是相同的(即不出现在请求标头中)http://localhost:3000

Answer 1

X-Forwarded-For不是RFC 2616第5.3节中规定的标准请求标头,它解决了协议标准请求标头(如RFC中所指定)

• 接受
• 接收字符
• 接受编码
• 接受语言
• 授权
• 期望
• 从
• 主办
• 如果-匹配
• 如果-Modified-Since的
• 如果 - 无 - 匹配
• 如果量程
• 如果未修饰的,因为
• 马克斯 - 前锋
• 代理授权
• 范围
• 引荐
• TE
• 用户代理

为了使您的传入请求具有自定义[X-Forwarded-For]标头,它必须由调用客户端显式添加到该请求.最简单的解释为什么你没有看到该标题是发送请求的客户端没有手动添加它.

棘手的是,您期望看到的标题不是您应该期望接收的标题,除非您的服务和调用者之间存在一个与HTTP协议分开的合同,表明您应该期望X -Forwarded-For值在请求标头中指定.正如其他人已经说过的那样,XFF标头通常由代理服务器或负载平衡器设置,以指示真实请求者是通过其代理执行的.

作为服务提供者,如果要求在所有请求中设置[X-Forwarded-For]标头,则必须在服务策略级别强制执行该标头.如果您不想为不能识别他们使用代理IP屏蔽的代理帐户提供服务,请使用403 Forbidden退回他们的请求.如果您处于必须为这些请求提供服务但依赖于此标头设置的情况,那么您将不得不提出一个自定义过程,您可以在其中回复它们的错误.

以下是HTTProtocol对匿名的评价:

由于链接源可能是私人信息或可能泄露其他私人信息源,因此强烈建议用户能够选择是否发送Referer字段.例如,浏览器客户端可以具有用于公开/匿名浏览的切换开关,其将分别启用/禁用发送Referer和From信息.

如果引用页面是使用安全
协议传输的,则客户端不应在(非安全)HTTP请求中包含Referer头字段.

使用HTTP协议的服务的作者不应该使用
基于GET 的表单来提交敏感数据,因为这会
导致这些数据在Request-URI中编码.许多现有
服务器,代理和用户代理会将请求URI记录在
第三方可能看到的某个位置.服务器可以使用
基于POST的表单提交而不是......

在每个请求中发送的精心制作的用户定制的接受标头字段,特别是如果这些包括质量值,可以被服务器用作相对可靠和长期存在的用户标识符.此类用户标识符将允许内容提供商进行点击跟踪跟踪,并允许协作内容提供商匹配跨服务器点击跟踪或形成单个用户的提交.请注意,对于不在代理后面的许多用户,运行用户代理的主机的网络地址也将用作长期用户标识符.在使用代理来增强隐私的环境中,用户代理在向最终用户提供接受头配置选项时应该保守.作为极端隐私措施,代理可以过滤中继请求中的接受标头.提供高度头部可配置性的通用用户代理应该警告用户可能涉及的隐私丢失.

就个人而言,我会使用401.2将请求退回,并通过WWW-Authenticate响应标头将请求者路由到挑战屏幕,该标头向他们提供不允许匿名访问您网站的通知.这是一种使用WWW-Authenticate标头的混合方式,但似乎您期望X-Forwarded-For标头能够确认并识别真实请求者并允许公共非匿名访问您的服务.对我来说,这是一个认证问题.

Answer 2

你为什么X-Forwarded-For 一开始就期待出现？您正在连接到运行在 上的 Web 服务器localhost，因此根本不涉及 ISP 提供商。即使您通过 ISP 连接到 Web 服务器，它仍然不太可能添加X-Forwarded-For到请求中。 X-Forwarded-For通常是由 HTTP 代理服务器或负载均衡器添加的，您不会经历这两个服务器。 X-Forwarded-For从未被网络浏览器包含。

Answer 3

• ISP 提供商不添加 X-Forwarded-For。
• X-Forwarded-For 不是让最终用户识别代理/平衡器背后的应用程序。
• X-Forwarded-For 用于代理/平衡器后面的应用程序来识别用户。

例如：您有 Web 应用程序（php、java 等）以及 http 服务器（Apache、nginx 等）然后：

1. 用户向 http 服务器发出请求。
2. Http 服务器将请求重定向到使用 X-Forwarded-For 作为用户 IP 的 Web 应用程序。
3. 您的 Web 应用程序知道它位于 http 服务器后面，因此它确实将 X-Forwarded-For 读取为用户 ip。