カスタムHTTPヘッダー：命名規則

何人かのユーザーから、自分のアカウントに関連するデータを、私たちが送信するリクエストのHTTPヘッダー、またはAPIから受け取るレスポンスに含めるように依頼されました。名前付け、形式などに関して、カスタムHTTPヘッダーを追加するための一般的な規則は何ですか？

また、あなたが偶然見つけたこれらのスマートな使用法をウェブに投稿してください。私たちはこれをターゲットとして最善のものを使用してこれを実装しようとしています:)

推奨はされて いた「X-」で自分の名前を開始します。例えばX-Forwarded-For、X-Requested-With。これはRFC 2047のセクション5でも言及されています。

アップデート1：2011年6月、非標準ヘッダーに「X-」プレフィックスを使用することの推奨を廃止するために、最初のIETFドラフトが投稿されました。その理由は、「X-」で始まる非標準ヘッダーが標準になると、「X-」プレフィックスを削除すると下位互換性が失われ、アプリケーションプロトコルが両方の名前をサポートするように強制されるためです（たとえば、x-gzip＆gzipは同等になりました）。したがって、正式な推奨事項は、「X-」プレフィックスを付けずに、適切に名前を付けることです。

更新2：2012年6月、「X-」プレフィックスを使用することの推奨の廃止はRFC 6648として公式になりました。以下は関連性のある引用です。

3.新しいパラメーターの作成者への推奨事項

...

3. パラメータ名の前に「X-」または同様の構成体を付けないでください。

4.プロトコル設計者への提言

...

4. "X-"プレフィックスまたは同様の構造を持つパラメータの登録を禁止する必要があります（SHOULD NOT）。

5. 「X-」接頭辞または同様の構造を持つパラメータは、標準化されていないものとして理解する必要があることを規定してはなりません。

6. 「X-」接頭辞または同様の構成のないパラメータは、標準化されたものとして理解する必要があることを規定してはなりません。

「SHOULD NOT」（「非推奨」）は「MUST NOT」（「禁止」）と同じではないことに注意してください。これらのキーワードの別の仕様については、RFC 2119も参照してください。言い換えれば、「X-」プレフィックス付きヘッダーを引き続き使用できますが、公式には推奨されておらず、パブリック標準であるかのようにドキュメント化することはできません。

まとめ：

• 公式の推奨事項は、「X-」接頭辞なしで、それらを適切に名前を付けることです。
• "X-"プレフィックス付きヘッダーを引き続き使用できますが、公式には推奨されておらず、パブリック標準であるかのようにドキュメント化することはできません。

質問は再読に耐えます。尋ねられる実際の質問は、CSSプロパティのベンダープレフィックスとは異なります。CSSプロパティでは、ベンダーサポートと公式の標準について将来の保証と考えが適切です。実際に尋ねられる質問は、URLクエリパラメータ名を選択することに似ています。誰も彼らが何であるか気にすべきではありません。しかし、カスタムのものを名前空間で区切ることは、完全に有効であり、一般的で正しいことです。

理論的根拠：カスタムのアプリケーション固有のヘッダー（「アカウントに関連するデータ」）の開発者間の規約
に関するものであり、ベンダー、標準化団体、またはサードパーティによって実装されるプロトコルとは何の関係もありません。問題は、サーバー、プロキシ、またはクライアントによる他の使用目的を持つ可能性のあるヘッダー名を回避することだけです。このため、「X-Gzip / Gzip」および「X-Forwarded-For / Forwarded-For」の例は参考になりません。提起された質問は、URLクエリパラメータの命名規則に似た、プライベートAPIのコンテキストにおける規則に関するものです。それは好みと名前の間隔の問題です。「X」のないプロキシまたはベンダーによって「X-ClientDataFoo」がサポートされていることに関する懸念

「X-」プレフィックスについて特別なまたは魔法のようなものはありませんが、カスタムヘッダーであることを明確にするのに役立ちます。実際、RFC-6648などは、「X-」プレフィックスの使用のケースを強化するのに役立ちます。これは、HTTPクライアントおよびサーバーのベンダーがプレフィックスを放棄するため、アプリ固有のプライベートAPI、個人データ通過メカニズムは、少数の公式の予約済みヘッダー名との名前空間の衝突に対してさらに適切に絶縁されています。そうは言っても、私の個人的な好みと推奨事項は、さらに一歩進んで、たとえば「X-ACME-ClientDataFoo」を実行することです（ウィジェット会社が「ACME」の場合）。

私見IETF仕様は、OPの質問に答えるには十分に具体的ではありません。それは、完全に異なるユースケースを区別できないためです。アプリ開発者がアプリ固有の文字列をクライアントとサーバー間でやり取りします。仕様は前者（A）にのみ関係します。ここでの問題は、（B）の規約があるかどうかです。がある。それらには、パラメーターをアルファベット順にグループ化し、タイプ（A）の多くの標準関連ヘッダーからそれらを分離することが含まれます。「X-」または「X-ACME-」接頭辞の使用は、（B）にとって便利で正当であり、（A）と競合しません。（A）の「X-」の使用をやめるベンダーが増えるほど、（B）のベンダーはより明確になります。

例：
Google（さまざまな標準化団体で少々の重みを持っている）は-今日、私の回答のこのわずかな編集で20141102-現在、 "X-Mod-Pagespeed"を使用してApacheモジュールのバージョンを示しています。特定の応答の変換に関与します。Googleが「X-」なしで「Mod-Pagespeed」を使用すること、および/またはIETFにその使用を祝福するように依頼することを本当に提案している人はいますか？

概要：
アプリ内でカスタムHTTPヘッダーを（Cookieの適切な代替手段として）使用してサーバーとの間でデータをやり取りしている場合、これらのヘッダーは明示的に、あなたのコンテキスト以外で使用することを意図していませんアプリケーションでは、「X-」または「X-FOO-」接頭辞を付けて名前をスペースで区切るのが合理的で一般的な規則です。

HTTPヘッダーの形式は、HTTP仕様で定義されています。仕様がRFC 2616であるHTTP 1.1について説明します。セクション4.2、「メッセージヘッダー」では、ヘッダーの一般的な構造が定義されています。

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

この定義は、トークンとテキストという2つの主要な柱に基づいています。どちらもセクション2.2、「基本ルール」で定義されています。トークンは：

   token          = 1*<any CHAR except CTLs or separators>

次に、CHAR、CTL、およびセパレーターで休憩します。

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

テキストは：

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

LWSは線形空白であり、その定義は再現しません。OCTETは次のとおりです。

   OCTET          = <any 8-bit sequence of data>

定義に注意書きがあります：

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

つまり、2つの結論です。まず、ヘッダー名はASCII文字のサブセットから構成される必要があることは明らかです。次に、ASCIIに制限したり、8ビット文字を除外したりするヘッダー値の定義には何もありません。これは、オクテットで明示的に構成され、制御文字のみが禁止されています（CRとLFは制御と見なされることに注意してください）。さらに、TEXTプロダクションに関するコメントは、オクテットがISO-8859-1であると解釈されること、およびそのエンコーディングの外の文字を表すためのエンコーディングメカニズム（偶然にも恐ろしい）があることを示唆しています。

したがって、特に@BalusCに応答するには、仕様に従って、ヘッダー値がISO-8859-1にあることは非常に明確です。私はTomcatからヘッダーに8859-1の高文字（具体的にはフランス語で使用されるアクセント付き母音）を送信し、Firefoxで正しく解釈させたので、これは実際にも理論上もある程度機能します（これはURLを含むLocationヘッダーでしたが、これらの文字はURLでは正しくありません。そのため、これは実際には違法でしたが、別の規則でした！）。

そうは言っても、すべてのサーバー、プロキシ、およびクライアントで動作するISO-8859-1には依存しないので、防御的プログラミングの問題としてASCIIを使用します。

RFC6648では、カスタムヘッダーが「標準化され、公開され、一般的に展開されるか、複数の実装で使用できるようになる」と想定することをお勧めします。したがって、「X-」または同様の構成要素をプレフィックスとして付けないことをお勧めします。

ただし、「[ヘッダー]が標準化される可能性が非常に低い場合」という例外があります。そのような「実装固有および私用」ヘッダーについては、RFCはベンダープレフィックスなどの名前空間は正当化されると述べています。

HTTPヘッダーを変更する、より正確には、追加することは、他に何もなければ、優れたコードデバッグツールです。

URLリクエストがリダイレクトまたは画像を返す場合、デバッグコードの結果を一時的に書き込むhtml "ページ"はありません-少なくともブラウザに表示されるものはありません。

1つの方法は、データをローカルログファイルに書き込み、そのファイルを後で表示することです。もう1つは、デバッグされるデータと変数を反映するHTTPヘッダーを一時的に追加することです。

X-fubar-somevar：やX-testing-someresult：のような追加のHTTPヘッダーを定期的に追加して、テストを行います。そうでなければ、追跡が非常に困難であった多くのバグを発見しました。

ヘッダーフィールド名レジストリはRFC3864で定義されており、「X-」には特別なものはありません。

私の知る限り、プライベートヘッダーのガイドラインはありません。疑わしい場合は避けてください。または、HTTP拡張フレームワーク（RFC 2774）をご覧ください。

ユースケースをさらに理解することは興味深いでしょう。なぜメッセージ本文に情報を追加できないのですか？