HTTPヘッダーのX-は非推奨と言うけれど・・・
2012年にRFC-6648でHTTPのヘッダーフィルドも含めて、X-はやめようとなりました。
X-の歴史
HTTPのヘッダーでは非標準ヘッダーにX-をつけるという慣習が長らく利用されていました。最初に導入されたのはRFC-822という電子メールのためのRFCで、この中では拡張フィールドという目的でした。
1982年のRFCから20年たって、RFC-2822というRFC-822の後継RFCで拡張フィールドはなくなりました。
X-廃止の範囲
ちなみにこれが対象としているのはHTTPヘッダーだけではありません。テキスト形式で名前をつけて何かを伝達させる「アプリケーションプロトコル」全般がターゲットのようです。
- media types
- header fields in Internet mail messages and HTTP requests
- vCard parameters and properties
- URN
- LDAP field name
なぜX-がダメかというと、すでに、X-なヘッダーが広まってしまったケースが数多くあるし（X-Forwarded-Forとか）、標準化されたらX-をはずそう、というのも、既存のシステムへの影響を考えるとなかなか実行できず、仕方なしに新旧両方対応しましょう、というルールになってしまうこともあったからとのこと。
じゃあどうすれば良いのか・・・
じゃあ、ちょっとしたヘッダーを独自に定義したい場合どうしましょうか、という話ですが、上記のRFCでは、「いったん公開されたら、それが広まって一般化され、複数の実装が出てきて標準化されるかもしれない、という覚悟を持て」
（意訳）的なことが書かれていました。宝くじを買ったら、当たってしまう可能性があるのだから気を引き締めて用途を考えておけ、的な（ちょっと違）
このRFCで言っているのは、似ているような名前があった場合も、別の単語をうまく探してきて使おう（例：Priority→Urgency）とか、もしパラメータ名をどうしても短くする必要があれば数値を割り振って使う、みたいなことも書かれています。あるいは、プライベートであることが確実であれば、ベンダープリフィックスやドメインのようなものを付けたり（ExampleInc-foonなど）をつける、本当に実験的な属性ならハッシュ値とか意味のない名前をつけたり、いっそのことUUIDで良くね？的なことまで書かれていました。知人からは「（ベンダープリフィックスをつける場合）Future-はかっこよくてずるい」と言われましたので、かっこいいベンダープリフィックスを使いたい場合はうちの会社を受けてくださってもよいと思います。
さすがにUUIDはどうなの、とは思いますが、社内システムとかだったら、ベンダープリフィックス方式がまあ良いのかな、と思いました。
個人的に、well-known URIでフロントエンドとサーバー間の決め事を交換したり、例えばヘルスチェックとかも/.well-known/statusとかで良くね？みたいに思っていたものの、自分で作ったときにはまだ知られてないからwell-knownは名乗るのは詐欺じゃね？と思いつつ、じゃあいつまでも作れないから/.well-knownに慣れないじゃん、詰んでるじゃん、と思っていたのですが、おそらくこのアプリケーションプロトコルにはwell-known URIも入りそうな気がする（名言されていないが）ので、/.well-known/future-なんとか、みたいなルールでアプリを作ってみようかと思いました。
Discussion