もともとX-Forwarded-Forを調べていたが前段としてX-hogehoge（以下X接頭辞）についてまとめる。なお和訳はほとんど powered by Google翻訳
出典
このX接頭辞非推奨についてまとめられているRFC6648にそもそもX接頭辞はどう始まったかも含めてまとまっている。
RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
X接頭辞のはじまり（RFC6648の付録Aより）
その記述によると最初はFTPのRFC691に記載されている以下の記述が始まり
I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies （本当にローカル特異パラメータは、複数の文字にすることにし、最初の文字をXにすることをお勧めします） - RFC 691 - One more try on the FTP
またFTPではX接頭辞は使われ…
FTP allows "experimental" commands, whose names begin with "X". If these commands are subsequently adopted as standards, there may still be existing implementations using the "X" form.... ( FTPでは、名前が"X"で始まる"実験的"コマンドを使用できます。これらのコマンドがその後標準として採用される場合でも、"X"形式を使用した既存の実装がまだ存在する可能性があります。) - RFC 1123 - Requirements for Internet Hosts - Application and Support
その後、メールのヘッダにも使われるようになり、RFC1154にて以下の記述が登場する。
Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". ( "X-" で始まるキーワードは、実装固有の使用のために永久に予約されています。 " X-" で始まる標準の登録済みエンコーディングキーワードはありません。 )
このメールヘッダでの利用を倣ってほかのものでも踏襲されたとされている。（ただしこのあとメールヘッダでの利用は非推奨となる）
バックグラウンドの説明ではこのようにX接頭辞が使いたくなる場面として「標準化される可能性のあるような実験的なもの」や「決して標準化されないような拡張機能」があるとしている。
またこのX接頭辞使用するのは仕様を作る側の個別の選択であり、それをうまく取り込んでいるRFCもあると説明がされている。
X接頭辞の現況
出典のRFC6648によって、2012年6月からはX接頭辞は非推奨となっている。RFC6648では非推奨に関しての前置きで以下のように記述している。
In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space. ( 要するに、理論的には"X-"規則は、標準化されたパラメータと標準化されていないパラメータの間の衝突（および付随する相互運用性の問題）を回避するための良い方法でしたが、実際には、標準化されていないパラメータが標準化されたパラメータへと変わってしまうコストがメリットを上回ってしまっています。 )
これは元となったメールヘッダなどがX接頭辞として始まったものが標準化されXを使用しないものとして動かされる事例があることを元に、置き換える際の様々なコストがかかることを懸念して、廃止にすべき…ということのようだった。
X接頭辞を使いたくなる場合どうするべきか
RFC6648には「新しいパラメータの作成者への推奨事項」という記載があり
- SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations.(それらが作成するすべてのパラメータが、標準化され、公開され、一般に展開され、または複数の実装にわたって使用可能になる可能性があると想定する必要があります。)
- SHOULD employ meaningful parameter names that they have reason to believe are currently unused.(現在未使用であると考える理由がある意味のあるパラメーター名を使用する必要があります。)
- SHOULD NOT prefix their parameter names with "X-" or similar constructs. (パラメータ名の前に「X-」または同様の構成体を付けないでください。) - RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
というように、そのあと標準化される懸念をしながらX接頭辞に近しいものは使うな、というように念押しされている。
独自ヘッダの事例
思いをはせる、というようなガイドラインになっているが、具体的にはどうするといいのか、他社事例としてOpenStackの事例があった。
OPENSTACKではこのRFCを前提において以下のように OpenStack 接頭辞をつけることをしている。以下説明の抜粋です。
To do this, use “OpenStack” and the service name in the header. An example might be “OpenStack-Compute-FooBar”, which is unlikely to be standardized already or conflict with existing headers.(これを行うには、「OpenStack」とヘッダーのサービス名を使用します。たとえば、「OpenStack-Compute-FooBar」は、すでに標準化されているか、既存のヘッダーと競合する可能性が低いです。) - HTTP Header Guidelines — API Special Interest Group documentation
このように基本的にあるコンテキスト固有のものはこのようにそのコンテキストを象徴する文字列がいいのかもしれないです。
関連リンク
- HTTP ヘッダー - HTTP | MDN
- RFC 4229 - HTTP Header Field Registrations - HTTPヘッダのベースとなるリスト、このリストからIANAにてヘッダの登録管理を行っている
