上回我写了一篇文章介绍「Referrer Policy」,有小伙伴看完后问我:Referrer 这个单词到底怎么拼,为什么有时候中间有两个
r
,有时候只有一个?
是的,这是一个很有趣的问题,这里就给有疑惑的同学们科普下。
HTTP 协议中有一个用来表示页面或资源来源的请求头,由 Philip Hallam-Baker 于上世纪 90 年代提出来,他当时把这个请求头叫做
Referer
,并最终写进了 RFC1945,也就是 HTTP/1.0 协议:
The Referer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. via
有趣的是,当时这个单词被他拼错了,正确的拼写应该是 Referrer
。但是这个错误被发现之前,已经被大量使用,如果要改过来需要所有服务端、客户端
的一致配合,还有大量的代码需要排查修改。于是,HTTP 的标准制定者们决定将错就错,不改了。下面这段描述来自于 RFC2616,也就是著名的
HTTP/1.1 协议:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) via
可以看到,相比 HTTP/1.0,HTTP/1.1 除了加上了对这个错误的说明之外,没有其他变化。另外,那个 [sic]
是拉丁文里「原文如此」的意思。很多其他标准在表述 HTTP 中的 Referer
请求头时,都会加上 [sic]
,避免引起读者误解。
由此可见,HTTP 标准制定者奉行实用主义,能用就行。由于 HTTP 协议继续拼错,浏览器当然只好按错的来,服务端收到的也是拼错的,所以大部分 Web Server、服务端语言或框架,都跟着拼错。举几个例子:
这里说的 JavaScript,都是针对宿主为浏览器的场景,获取到的 referrer 属性都是由浏览器提供的。这一次,浏览器们比较齐心,都采用了正确的拼写方式,没有让这个错误在 JavaScript 中延续。
例如 DOM Level 2 里定义的 document.referrer
:
Returns the URI [IETF RFC 2396] of the page that linked to this page. The value is an empty string if the user navigated to the page directly (not through a link, but, for example, via a bookmark). via
最新的 Fetch API 中的 Request 接口,也有一个名为 referrer
的属性:
The referrer attribute's getter must return the empty string if request's referrer is no referrer, "about:client" if request's referrer is client and request's referrer, serialized, otherwise. via
更多关于 Fetch API 的介绍可以查看月影大大翻译的这篇文章:这个API很"迷人"----(新的Fetch API)。
其他标准,例如 Referrer Policy,也采用了正确的写法,并且明确表示不会兼容错误的拼写,例如在 Delivery via CSP 这一节写着:
Note: The directive name does not share the HTTP header's misspelling.
HTTP 请求中的 Referer
是一个典型的拼写错误,历史悠久,可以预见还会一直错下去。也许以后 Referer
会变成一个专有名词也说不定。所以,一般涉及到读取 HTTP 请求头的场景,我们需要用 Referer
这种错误拼写;除此之外一般都要用
Referrer
这种正确的拼写。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8