拡張宣言

拡張宣言 (HTTP)

[21] 拡張宣言 (extension declaration) は、 HTTPメッセージに適用される拡張を宣言するものです。 HTTPヘッダー Man:, C-Man:, Opt:, C-Opt: は、拡張宣言を含めるものです。

本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。

(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)

目次

  1. 仕様書
  2. 意味
  3. 構文
  4. 文脈
  5. 処理モデル
  6. 引数
  7. 歴史
  8. 関連

仕様書#

意味#

[2] 拡張宣言は、当該メッセージに拡張が適用されることを示すとともに、 ヘッダー接頭辞名前空間を予約するものです >>1

[10] 拡張は、絶対URLヘッダー名で識別します。 ヘッダー名IETF 標準化過程RFC で定義されたヘッダーの名前でなければなりません>>1

[11] ヘッダー名を指定できるのは、絶対URLで定義された拡張から IETF 標準化過程RFC で規定された標準仕様への移行のためと説明されています >>1

[20] 拡張宣言は、必須 (mandatory) のものと任意選択 (optional) のものがあります >>19Man:C-Man: には必須の拡張宣言を指定できます。 Opt:C-Opt: には必須の拡張宣言を指定できます。

[23] 拡張宣言は、ホップ毎のものと末端対末端のものがあります >>19ホップ毎拡張宣言は、当該HTTP接続にのみ適用されます >>19C-Man:C-Opt: にはホップ毎拡張宣言を指定できます >>19Man:Opt: には末端対末端拡張宣言を指定できます >>19

構文#

[27]ヘッダーの値は、1つ以上の拡張宣言リスト (#) です >>19

拡張宣言OWS,OWS拡張宣言

[4] 拡張宣言は、 " で括った絶対URLまたはヘッダー名の後に、 0個以上の ;引数を指定したものです >>1

[6] 仕様書の時代的に構文上明記されていませんが、 ; の前後には OWS が挿入できると思われます。
"絶対URLヘッダー名"OWS;OWS引数
[5] 絶対URLRFC 2068 を通じて RFC 1738 の定義が参照されています。 非ASCII文字は使えません。
[3] 絶対URLは必ず : を含み、ヘッダーは必ず含まないので、 両者は曖昧なく区別できます。

[7] 引数は、名前のみか、名前と値を = で連結したものです >>1

[8] 名前は字句です >>1

[17] 大文字・小文字不区別と思われますが、明記されていません。唯一定義されている ns 引数は構文上不区別となっています >>1

[9] 値は字句または引用文字列です >>1

字句=字句引用文字列

文脈#

[26] 任意選択の拡張宣言は、どのHTTPメッセージにも指定できます >>19, >>34

[28] C-Man:, C-Opt: およびこれらで宣言されたヘッダー接頭辞から始まるヘッダーの名前は、 Connection: に指定しなければなりません >>19

[31] 必須の拡張宣言を含む要求必須要求 (mandatory request) といいます。 必須要求の要求メソッドM-* でなければなりません>>19

[35] は、必須の要求に対する応答で、または対応していることが事前に分かっている受信者に対してを除き、 必須の拡張宣言を送信してはなりません >>34

[40] SSDPM-SEARCH 要求でも MAN: を使います >>39

[42] SSDPNOTIFY 要求OPT:ヘッダー接頭辞から始まるヘッダーを使った例も示されています >>41

処理モデル#

[25] 任意選択の拡張宣言受信者は、拡張で指定された規則に従っても構いませんし、 拡張を無視しても構いません >>19, >>30

[24] 必須の拡張宣言受信者は、拡張で指定された規則に従わなければなりません >>19, >>30。従えない時は、 510 応答を返さなければなりません >>30

[29] 末端対末端またはホップ毎の必須の拡張宣言を受信し、 その拡張をすべて理解して処理できたは、 応答にそれぞれ Ext:C-Ext: を指定しなければなりません >>30

[33] Ext: も参照。

[32] 必須の拡張宣言を処理する受信者でないは、 転送時に拡張宣言を削除してはなりません >>30

[36] クライアントが理解できない、または使いたくない必須の拡張宣言応答に含まれていた場合には、 500 応答が返されたかのように扱うべきです >>34

引数#

[12] 構文上 ns が最初の引数でなければならないようになっています >>1

[13] 実際に順序に意味があるのかは不明です。

[14] 拡張の引数を使っても構いませんが、受信者が認識することは保証できません。 拡張の実現値データ (instance data) を伝えるために引数を使ってはなりません>>1

[18] 引数の名前が重複して良いのかは不明です。

[15] 未知の引数は無視するべきです >>1転送時に削除してはなりません >>1

[16] 次の引数があります。

歴史#

[38] RFC 4229RFC 2774 を出典にこれら4ヘッダーを状態「実験的」 でIANA登録簿に登録しています >>37

関連#

[22] 意味的にはXML名前空間名前空間宣言と似ています。