Web開発をしていると、HTTPヘッダーに登場する「Referer」という表記を目にする機会があります。しかし英単語としては「Referrer」が正しいように見えるため、なぜHTTP仕様では「Referer」と書かれているのか疑問に感じる人も少なくありません。
この記事では、HTTPヘッダーのRefererという表記の由来、Referrerとの違い、そして開発現場で表記を間違えた場合にどのように考えるべきかについて詳しく解説します。
HTTPヘッダーのRefererは正式な仕様上の表記
HTTPリクエストヘッダーには「Referer」というフィールドがあります。これは、ユーザーがどのページから現在のページへ移動してきたのかを示す情報を送信するために使われます。
例えば、ユーザーが検索結果ページからWebサイトへアクセスした場合、ブラウザはRefererヘッダーに直前に閲覧していたURLを含めて送信することがあります。
英語としては「参照元」を意味する場合、「Referrer」というスペルが一般的です。しかしHTTPの仕様では歴史的な理由から「Referer」という綴りが正式な名前として採用されています。
なぜRefererはスペルミスのまま使われているのか
Refererという表記は、HTTP仕様が作られた初期段階で発生した単純なスペルミスが原因とされています。
本来であれば「Referrer」となる予定でしたが、仕様策定時に誤ったスペルが使われ、その後多くのWebブラウザやサーバーが対応したため、互換性の問題から修正されませんでした。
インターネットの世界では、一度広く普及した仕様を変更すると大量のシステムに影響が出るため、誤った表記であっても正式仕様として残ることがあります。
Referrerと書くことは間違いなのか
プログラム内の変数名やコメント、ドキュメントなどで「Referrer」と書くこと自体は間違いではありません。むしろ英語として自然な表記なので、独自のコード内ではReferrerを使用する開発者もいます。
ただし、HTTPヘッダー名を扱う処理では注意が必要です。HTTP仕様上のフィールド名は「Referer」であるため、リクエストヘッダーを取得するときに「Referrer」と書いてしまうと、別の名前として扱われて正常に取得できません。
例えばJavaScriptやサーバーサイドの処理でアクセス元URLを取得する場合、ブラウザやフレームワークが提供する仕様に合わせてRefererという名称を使用する必要があります。
プログラマーとして知っておくべきポイント
プログラミングでは、単なる英単語の正しさよりも、仕様や既存のルールに従うことが重要です。HTTPのRefererもその代表的な例です。
例えば、HTMLの仕様に存在する「charset」や、プログラミング言語の予約語などにも、歴史的な理由で現在の一般的な表記とは異なるものがあります。
そのため、RefererをReferrerと書いてしまった経験だけでプログラマーとして失格になることはありません。重要なのは、間違いに気付いた後に仕様を確認し、正しく扱えるかどうかです。
実務でRefererを扱うときの注意点
Refererヘッダーを利用するときは、必ず送信されるとは限らない点にも注意が必要です。ユーザーのプライバシー設定やブラウザの設定、HTTPSからHTTPへの移動などによって情報が送られない場合があります。
また、Refererの値はユーザー側から送信される情報であるため、認証やセキュリティ判定の唯一の根拠として利用することは避ける必要があります。
例えばアクセス制限をRefererだけで行うと、簡単に偽装される可能性があります。そのため、認証情報やCSRF対策など、別のセキュリティ対策と組み合わせて利用することが大切です。
まとめ
HTTPヘッダーの「Referer」は、英語としては不自然な表記ですが、HTTP仕様として正式に定義されている名称です。
Referrerと書いてしまったからといって、プログラマーとして失格ということはありません。ただし、HTTPヘッダーを扱うコードでは仕様通りRefererを使用する必要があります。
Web技術では歴史的な経緯によって現在も使われ続けている表記が数多く存在します。大切なのは、暗記した英単語ではなく、仕様を確認して正しく実装する姿勢です。
コメント