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

仕様書

意味

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

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

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

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

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

構文

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

  1. 拡張宣言
  2. *
    1. OWS
    2. ,
    3. OWS
    4. 拡張宣言

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

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

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

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

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

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

  1. 字句
  2. ?
    1. =
    2. |
      1. 字句
      2. 引用文字列

文脈

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

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

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

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

[40] SSDP の M-SEARCH 要求でも MAN: を使います >>39。

[42] SSDP の NOTIFY 要求で 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 4229 が RFC 2774 を出典にこれら4ヘッダーを状態「実験的」 でIANA登録簿に登録しています >>37。

関連

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