😭

あれ？スペルミス？ Referer ヘッダーの歴史を紹介

に公開
http
RFC
歴史
idea

はじめに

ある日のコードレビュー中に HTTP ヘッダーの Referer が目に留まりました。「あれ？タイポかな？」と思い MDN で調べると確かに Referer で正しいのですが、気になる一文がありました。

なお、 referer は実際には "referrer" という単語のスペルミスです。
詳しくは Wikipedia の HTTP リファラを参照してください。

引用元: https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Referer

なぜスペルミスのヘッダー名が標準として利用されているのか気になったので、今回はその歴史的な背景を紹介します。

HTTP Referer のスペルミスが残り続ける歴史

1. タイポ誕生の瞬間 ― Hallam‑Baker のワンミス

1994 年ごろ、CERN 出身のセキュリティ研究者 Phillip Hallam‑Baker は「リンク元 URL をサーバーに知らせるフィールドが欲しい」と思い立ち、HTTP‑WG メーリングリストに仕様追加を提案しました。そのメールで彼は、うっかり “referrer” から r を落とした Referer とタイプしてしまいます。

本人も「スペルチェッカーがどちらも認識しなかったし、動けば問題ないと思った」と後日語っています。共同執筆者の一人である Roy Fielding は、当時の標準的な Unix スペルチェッカーが「referrer」も「referer」も認識しなかったと述べています。このため、誰もスペルミスを指摘できないまま標準入りを果たしました。

このスペルミスは、フィールドが Request for Comments（RFC）標準文書である RFC 1945 に組み込まれる時点で確定していましており、RFC 1945 は 1996 年に発行されました。

Hallam‑Baker は後に、自身の綴りが「1 分間に何十億回も使われている」ため、オックスフォード英語辞典に採用されるよう冗談を言っていたとされています。
また、Hallam‑Baker は後に「僕の綴りが 1 分間に何十億回も使われているんだから、Oxford English Dictionary も採用してくれないかな」とも冗談を飛ばしていたそうです。

2. 後方互換性がつなぐスペルミスの歴史

“いまさら直せない” という現実

RFC 公開後、すでに多くのシステムや依存関係が存在していたため、スペルミスが認識された後も、変更するには遅すぎました。互換性を維持するために、このスペルミスはそのまま維持されることになります。これは、過去のシステムの望ましくない特徴を正確に再現する「bug compatibility」（バグ互換性）と呼ばれる現象の一例として挙げられています。

年 主な出来事 影響
1996 RFC 1945 発行 Referer が正式仕様に
1997 RFC 2068 (HTTP/1.1) 発行 節14.37 に “Referer [sic]” と脚注付きで原文ママの綴り誤りであることを明示
2017 Referrer Policy の誕生 リファラー情報を制御する Referrer-Policy が誕生。こちらはスペルミスはなし。
2020– 主流ブラウザが既定で strict-origin-when-cross-origin を採用 クロスオリジン時はドメインのみ送信へ自動縮退。プライバシー保護が強化され、Referer の存在感はさらに薄まるがスペルは依然そのまま。

補足: Referer ヘッダーのプライバシー問題

誤記とは無関係に Referer はプライバシー漏えいの温床となることがあります。サーバーは、ユーザーがアクセスしている参照元ページや、要求されたリソースが使用されている場所を特定するためにこのデータを使用できますが、これはプライバシーとセキュリティ上の懸念を引き起こす可能性があるためです。

そのため、ブラウザは送信内容の制限を強めています。参照元情報を制御するために Referrer Policy が導入され、開発者は自身のWebサイトに対してリファラーポリシーを設定できるようになりました。これにより、機密性の高い情報が意図せず漏洩するのを防ぐことができます。

たとえば Referrer-Policy: strict-origin-when-cross-origin がデフォルト設定となり、このポリシーの挙動は以下の通りです。

  • 同一オリジンのリクエストでは、オリジン、パス、クエリ文字列を含む完全なURLが送信される。
  • クロスオリジンのリクエストでは、スキーム（プロトコル）とホスト（ドメイン）のみ（オリジンのみ）が送信される。
  • HTTPSからHTTPへのセキュリティレベルが低い宛先へのリクエストでは、Referer ヘッダーは送信されない。

皮肉にも、「綴りミスを修正する機会」は、新しいセキュリティ機能を追加し、Referrer-Policy のような新しいヘッダーを導入するたびに訪れました。実際に、Referrer-Policy ヘッダーの名称には、元の Referer ヘッダーのようなスペルミスは含まれていません。しかし、既存のReferer ヘッダー自体は、互換性を維持するためにスペルミスのまま温存されています。

まとめ

HTTP の Referer ヘッダーがスペルミスをしている理由は以下の通り歴史的な背景がありました。

  • Referer は HTTP/1.0 草稿の単純なタイポが由来で、そのまま RFC へ採用されました。
  • 誤記を修正できなかった主因は、Web 全体の互換性維持という現実的な制約によるものです。
  • 現在はプライバシー保護の観点から Referrer-Policy が推奨され、運用時は送信内容を最小化するのがベストプラクティスとなっています。

参考文献

  1. https://datatracker.ietf.org/doc/html/rfc1945
  2. https://datatracker.ietf.org/doc/html/rfc2068
  3. https://news.ycombinator.com/item?id=16286764
  4. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer
  5. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
  6. https://www.w3.org/TR/referrer-policy/
  7. https://stackoverflow.com/questions/3087626
  8. https://en.wikipedia.org/wiki/Bug_compatibility
  9. https://stackoverflow.com/questions/3087626/was-the-misspelling-of-the-http-field-name-referer-intentional

Discussion