独自HTTPヘッダのX-接頭辞が非推奨になっていた話など
RFC6648
Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP headers.
RFC6648でX-プリフィクスの仕様廃止となっている。廃止についてのRFCというものもあるのだなあ。
標準化する際に旧パラメータを半永久的にサポートする必要があるなど移行コストがかかるということが主な理由らしい。しかし、標準化と非標準化で分離される意味がないという主張であるならばX-があっても問題がないはずでどうも論拠が弱い気がしてならない。
標準化の際にセキュリティ上の理由などで仕様が変更されても追従されないような話はまた別の問題なのでプリフィクスの有無の問題ではないだろう。実際のところ「なくてもよいだろう」という話はその通りとも言えるけれど、「つけるべきではない」という話とは別問題で少しネットを見ていても似たように納得していない人はそれなりにいそうだった。
さておき、こういう流れであれば自分が設計する仕様ではプリフィクスはないように命名する気がするけれど、ベンダ?固有の仕様であることを明示できるようになんらかの接頭辞は付加するのだろうなあ。
well-known URI
RFC6648について調べていた最中に、Real World HTTPなどの著者である渋川よしき氏の記事 HTTPヘッダーのX-は非推奨と言うけれど・・・ でwell-known URIへの言及をみつけた。
/.well-known はスマートフォンアプリ向けの対応で apple-app-site-association や assetlinks.json を配置するようなことはあっても詳しく理解しているわけではいなかったが、各サーバで同じパスを参照すればいいように標準化されている話で古くからの仕組みだと robots.txt や crossdomain.xml などの延長として策定されたように思われる。
RFCでは8615が該当するようだ。
ヘッダ名どうするの流れからなので、ここでも命名（パス）をどの程度衝突に強くするかといった問題が出てきそうだが、IANAに登録済みの命名もすでにだいぶカオスな印象なので結構やりたい放題のインターネットを感じる。
ヘルスチェックなんかをこういうパス配下に置くのはよさそうに思ったけれど、あまりそういう話が出ている雰囲気ではないのか。ヘルスチェックなんかはある程度標準化してほしいような仕組みであるけれど、細かいニーズが必要なケースとそうでないケースがあるので最小公倍数だと仕様は膨れがちになりそう。
共通フォーマットを策定しようという動きはあって、これは仕様の標準化とは異なるのだけれど応答情報の命名や構造で参考にしている。
Appleが提唱して、SafariやChromeでは既に利用可能な /.well-known/change-password は実用的で良い仕組みだなあとは思った。すべての会員制サービスで /.well-known/cancel-membership 用意してほしい。
