In some cases the HTTP Referer header can be very important to web administrators. Some organizations use them to track when business partners refer users to their website. There may even be a pay-per-reference contract. In such cases it is imperative that referral header tracking is accurate. In some reverse proxy deployments, this scenario can have some unexpected results in which the proxy plays a role.
 

For example:

- Site A has a partnership with Site B
- Site B needs to track all the Referer headers that consist of site A's host name (web address)
- Site A has a reverse proxy deployment which maintains secure connections (SSL)
- Site B hosts content strictly over HTTP

When a user clicks on a link on site A (secure site) that sends them to site B (non-secure site), the client will be leaving a secure connection to a non-secure connection. For security purposes, the Referer header will be stripped to conceal the host name (web address) of the secure site. For troubleshooting purposes, if you take the proxy which maintains the secure connection out of the equation, the Referer header will be sent. This might lead an administrator to believe that the proxy is misbehaving and causing the Referer header to be stripped when in fact it is being stripped by the client's browser. 

RFC 2616, 15.1.3:
"Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

For more information:
http://tools.ietf.org/html/rfc2616

NOTE: The same can apply for a forward proxy deployment when the proxy is configured to redirect HTTP requests to HTTPS, but the example given above is a real-world scenario.