http - Reason for browser not showing X-Forwarded-For headers -

note: please read full question

i'm trying understand why browsers doesn't show me x-forwarded-for header every time request page

btw here request headers like

request url:http://localhost:3000/users/sign_in request method:get status code:304 not modified 

request headers:

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, gecko) chrome/32.0.1700.102 safari/537.36 

response headers(not need still )

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 

now said, dont see x-forwarded-for in request headers

reading through wiki pages of x-forwarded-for make me feel ,it done caching server(which in case believe isp provider) so safe believe **x-forwarded-for** headers added @ caching server side (isp provider)

if yes 1 bugging me

why? same true (i.e x-forwarded-for not appearing in request-headers ) server running locally on machine , accessing them via browser http://localhost:3000

x-forwarded-for not standard request header specified in rfc 2616 section 5.3 addresses protocol standard request headers, (as specified in rfc)

• accept
• accept-charset
• accept-encoding
• accept-language
• authorization
• expect
• from
• host
• if-match
• if-modified-since
• if-none-match
• if-range
• if-unmodified-since
• max-forwards
• proxy-authorization
• range
• referer
• te
• user-agent

in order incoming request have custom [x-forwarded-for] header, must explicitly added request calling client. easiest explanation of why not seeing header client sending request did not manually add it.

the tricky thing header expecting see is not header should expecting receive unless there contract in place between service , caller apart httprotocol indicating should expect x-forwarded-for value specified in request header. others have stated, xff header typically set proxy server or load balancer indicate real requester is acting through proxy.

as service provider, if demand [x-forwarded-for] header set in requests, must enforce @ service policy level. if not want service proxy accounts not identify shielding proxy ip, bounce request 403 forbidden. if in situation must service these requests depend on header being set, you're going have come custom process communicate error back.

here httprotocol has anonymity:

because source of link might private information or might reveal otherwise private information source, recommended user able select whether or not referer field sent. example, browser client have toggle switch browsing openly/anonymously, respectively enable/disable sending of referer , information.

clients should not include referer header field in (non-secure)
http request if referring page transferred secure
protocol.

authors of services use http protocol should not use get
based forms submission of sensitive data, because will
cause data encoded in request-uri. many existing
servers, proxies, , user agents log request uri in some
place might visible third parties. servers can use
post-based form submission instead ...

elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can used servers relatively reliable , long-lived user identifiers. such user identifiers allow content providers click-trail tracking, , allow collaborating content providers match cross-server click-trails or form submissions of individual users. note many users not behind proxy, network address of host running user agent serve long-lived user identifier. in environments proxies used enhance privacy, user agents ought conservative in offering accept header configuration options end users. extreme privacy measure, proxies filter accept headers in relayed requests. general purpose user agents provide high degree of header configurability should warn users loss of privacy can involved.

personally, bounce request 401.2 , route requester challenge screen via www-authenticate response header presents them notification not allowed anonymous access site. it's kind of bastardized way of using www-authenticate header, seems you're expecting x-forwarded-for header acknowledge , identify real requester , allowing public non-anonymous access service. me, that's authentication concern.