一、介绍
从一个文档发出的请求，以及从文档导航到其他页面，都会有一个Referer头。出于以下原因，我们有时会希望浏览器不发送referer头：
1.隐私
一个社交网站会有每个用户的简介页面，用户会在他们的个人主页中添加一些链接。社交网站可能不希望泄露用户的个人主页URL给被链接的网站（因为个人主页URL可能会泄露其主人的身份信息）。
一些社交网站可能想通知其他网站该链接是从社交网站发起的，但不想泄露包含用户信息的链接（例如，微博中的链接希望告诉对方该链接是在微博中连接过来的，但不希望告诉对方从谁的微博连接过来）。
2.安全
一个网站应用使用https和基于URL的会话标识。应用也许希望链接其他站点的https资源但不想泄露位于URL中的用户会话标识符。
或者，应用可以使用一些url自身的能力（如重置密码的链接、通过链接直接登录账号等）。控制referrer有助于阻止这些有特殊能力的url泄露referrer头。
注意，有其他方式避免这些url的泄露，控制referrer并不足以控制所有的泄露情况。
3.引用
基于HTTPS的博客可能希望连接到一个HTTP上的博客并收到引用链接。
二、referrer策略
Referrer策略包含以下值：
- 空字符串
- no-referrer
- no-referrer-when-downgrade
- same-origin
- origin
- strict-origin
- origin-when-cross-origin
- strict-origin-when-cross-origin
- unsafe-url
下面会详细讲解每种Referrer策略。
1.no-referrer
最简单的策略是“no-referrer”，表示所有的请求都不带referrer。
http://www.lyz810.com/demo/referrer/index.php?referrer=no-referrer
2.no-referrer-when-downgrade
主要针对于受TLS保护的URL（如https），简单的说就是https的页面中，当连接的资源也是https的，则发送完整的referrer，如果连接的资源是http的，就不发送referrer
https://www.lyz810.com/demo/referrer/index.php?referrer=no-referrer-when-downgrade
此例中，音乐可以播放，因为他是http的，不发送referrer，iframe可以显示referrer，因为是https协议。
这个是在没有特别指定referrer策略时，浏览器的默认行为。
3.same-origin
对于同源的链接，会发送referrer，其他的不会。同源意味着域名需要相同，example.com和not.example.com是非同源的。
http://www.lyz810.com/demo/referrer/index.php?referrer=same-origin
上面的例子中可以看到，音乐无法播放了（因为是他站资源），而iframe嵌套的同源页面仍然可以读到referrer。
4.origin
这个策略对于任何资源来说只发送源的信息，不发送完整的url。
http://www.lyz810.com/demo/referrer/index.php?referrer=origin
此例中，音乐无法播放，因为它发送了referrer，iframe中显示的referrer只包含源的信息，不包含完整的url。
5.strict-origin（浏览器可能不支持）
这个策略类似于origin和no-referrer-when-downgrade的合体，如果一个https页面中链接到http的页面或资源，则不会发送referrer。http页面链接以及https链接到https都只发送来源页面的源信息。
https://www.lyz810.com/demo/referrer/index.php?referrer=strict-origin
此例中，音乐正常播放，因为是http的资源，不发送referrer，而iframe中只有源信息。
6.origin-when-cross-origin
该策略在同源的链接中发送完整的URL，其他情况仅发送源信息。相同的域名，http和https协议被认为是非同源的。
http://www.lyz810.com/demo/referrer/index.php?referrer=origin-when-cross-origin
此例中，音乐不能播放，发送源信息，iframe显示完整url。
7.strict-origin-when-cross-origin（浏览器可能不支持）
对于同源请求，发送完整的URL；对于同为https的，只发送源信息；对于http页面只发送源信息；https页面中的http请求不发送referrer。
8.unsafe-url
这个主要是解决https页面中的http资源不发referrer的问题，它会使在https页面中http资源发送完整的referrer。
https://www.lyz810.com/demo/referrer/index.php?referrer=unsafe-url
此例中，音乐不能播放，虽然页面是https，资源是http，但unsafe-url使得浏览器仍发送referrer。
9.空字符串
空字符串表示没有referrer策略，默认为no-referrer-when-downgrade。
三、用法
Referrer策略可以通过以下方法声明：
1.通过http请求头中的Referrer-Policy字段
2.通过meta标签，name为referrer
3.通过<a>、<area>、<img>、<iframe>、<link>元素的referrerpolicy属性。
4.通过<a>、<area><link>元素的rel=noreferrer属性
5.通过隐式继承
四、用法举例
1.http请求头
Referrer-Policy: no-referrer
2.meta标签
<meta name=”referrer” content=”no-referrer” />
3.referrerpolicy属性
<a href=“http://example.com” referrerpolicy=“origin”>
4.rel=noreferrer属性
五、注意事项
Referrer策略还有其他历史遗留的值：
1.never等价于no-referrer
2.default等价于no-referrer-when-downgrade
3.always等价于unsafe-url
4.不建议使用上面三个值，建议使用后面的新值
六、兼容性
IE：不支持（IE高版本中隐式支持default，https页面拉取的http资源不会加referrer）
Edge：仅支持较早版本的值（never、always、origin、default）
Firefox：36+
Chrome：21+
Safari：7.1+（仅支持较早版本的4个值）
Opera：15+
iOS Safari：8+（仅支持较早版本的4个值）
七、关于防盗链
目前大部分网站采用的是判断referrer是否是当前域名或指定白名单域名下的url。而没有referrer的请求都会放行。
referrer策略普及后，单从referrer判断防盗链的方法会失效，所以需要考虑其他的技术手段实现防盗链机制。
很好~