[27] [DFN[[RUBYB[[[メッセージ]]]@en[message]]]]は、 [[HTTP]] における情報伝達の単位 ([[アプリケーション層]]の[[パケット]]) です。 [28] [[メッセージ]]には、[[要求メッセージ]]と[[応答メッセージ]]があります。 * 仕様書 [REFS[ - [30] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) -- [49] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) -- [514] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [13] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [517] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [2052] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) - [58] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2014-09-07 13:12:32 +09:00]] 版) - [61] [CITE[UPnP Device Architecture 2.0]] ([TIME[2014-09-05 02:24:48 +09:00]] 版) - [66] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) ]REFS] * テキスト形式メッセージ (HTTP/0.9, HTTP/1.0, HTTP/1.1) [65] [[HTTP/1.0]] と [[HTTP/1.1]] は、 [[RFC 822]] に由来するテキスト形式の[[メッセージ]]構文を採用していました。 [[HTTP/0.9]] はそれよりも更に単純な形式でした。 ** 構文 [29] [[メッセージ]]は、[[開始行]]、[[ヘッダー]]、[[メッセージ本体]]の3つの部分で構成されます [SRC[>>30]]。 [46] [[HTTP/0.9]] [[応答]]以外のすべての[[HTTPメッセージ]]には、 [[開始行]]が存在します。 [31] [[ヘッダー]]は、任意の個数使用することができ、必ず直後に [[CRLF]] が来ます。 [SRC[>>30]] ただし [[HTTP/0.9]] では[[ヘッダー]]を使うことができません。 [32] [[開始行]]および[[ヘッダー]]と[[メッセージ本体]]の間には、必ず1つ [[CRLF]] が来ます。 [SRC[>>30]] 最後の[[ヘッダー]]の後の [[CRLF]] ([[ヘッダー]]が無い場合は[[開始行]]の最後の [[CRLF]]) とあわせて、 [[CRLF]] [[CRLF]] と2回連続することになります。なお [[HTTP/0.9]] ではこの [[CRLF]] は存在しません。 [34] [[メッセージ本体]]は省略することもできます [SRC[>>30]]。 [[HTTP/0.9]] [[要求]]では[[メッセージ本体]]を使えません。 ;; [35] [[ヘッダー]]や[[メッセージ本体]]は省略できますが、いつでも省略できるわけではなく、他の色々な条件で制約されています。 [36] [[HTTP/1.x]] では、[[メッセージ本体]]がなくても、区切りの [[CRLF]] は必要です。 ;; [47] [[HTTP/0.9]] [[応答]]は、[[開始行]]と[[ヘッダー]]がなく、全体が[[メッセージ本体]]となります。 [FIG(railroad)[ = | == = === [[開始行]] === * ==== [[ヘッダー]] ==== [[CRLF]] === [[CRLF]] === ? ==== [[メッセージ本体]] == HTTP/0.9 要求 === [[開始行]] == HTTP/0.9 応答 === [[メッセージ本体]] ]FIG] ;; [57] [[プロトコルの版]]も参照。 [62] [[SSDP]] は [[HTTP/1.1]] と同じ[[メッセージ]]の構文を採用しています [SRC[>>61]]。 ** 構文解析 [42] [[HTTPメッセージ]]は[[ストリーム]]として[[構文解析]]して[[漸進的処理]]に供したり、 [[下流]]へ[[転送]]したりできます。しかし、[[実装]]によっては[[転送]]する[[メッセージ]]を[[バッファリング]]したり遅延させたりして調整したり何らかの処理を行ったりすることがありますから、 [[受信者]]は、[[メッセージ]]を[[漸進的]]に受信できることに依存できません。 [SRC[>>30]] ;; [43] と [[HTTP]] 仕様書は言っていますが、実際には[[鯖]]と[[クライアント]]の間の[[接続]]を維持し、 [[メッセージ本体]]中のデータを随時断続的に送信していくような使われ方がしばしばなされています。 [[メッセージ]]をすべて読み終わるまで[[転送]]できないような[[中間器]]は、 [[Web互換]]ではありません。 [41] [[受信者]]は、[[HTTPメッセージ]]を [[US-ASCII]] の[[超集合]]の[[オクテット列]]として[[構文解析]]しなければ[['''なりません''']]。 [SRC[>>30]] [37] 通常は [[HTTPメッセージ]]を次のように[[構文解析]]します [SRC[>>30]]。 [FIG(steps)[ = [38] [[開始行]]を読んで構造を解釈します。 = [39] [[空行]]に達するまで各[[ヘッダー]]を読んで、 [[ヘッダー名]]の[[ハッシュ表]]に入れます。 = [40] [[メッセージ本体]]があれば、[[メッセージ本体長]]分に達するか[[接続]]が閉じられるまでの[[オクテット]]を[[ストリーム]]として読みます。 ]FIG] [513] [[鯖]]は、少なくても1つは[[要求行]]の前の [[CRLF]] を無視する[['''べきです''']] [SRC[>>514]]。 ;; [[HTTP接続]]も参照。 [44] [[送信者]]は[[開始行]]と最初の[[ヘッダー]]の間に[[空白]]を[[送信]]しては[['''なりません''']] [SRC[>>30]]。[[受信者]]は、[[開始行]]と[[ヘッダー]]の間に[[空白]]があれば、 [[メッセージ]]を[[非妥当]]であるとして拒絶するか、 [[空白]]で始まる[[行]]を消費して無視するかのいずれかとしなければ[['''なりません''']] [SRC[>>30]]。 ;; [45] [[生成]]ではなく[[送信]]が禁止されているので、[[転送]]するだけの場合であっても、 [[空白]]をそのままにすることは禁止されています。 [48] [[メッセージ本体]]の項も参照してください。 [516] [[HTTP]] [[要求メッセージ]]のみを受け付ける[[鯖]]は、 [[HTTPメッセージ]]の文法に沿わない[[オクテット列]]を受け取った場合、 (他に規定がなければ) [CODE(HTTP)[[[400]]]] [[応答]]を送る[['''べきです''']] [SRC[>>514]]。 [55] [[Apache]] は[[ヘッダー部]]に[[ヘッダー]]でないもの ([CODE(HTTP)[[[:]]]] が含まれない[[行]]) が混じっていると [CODE(HTTP)[[[400]]]] を返します。 [[nginx]] は無視するようです。 [TIME[2014-10-24T06:04:05.600Z]] ;; [56] [CODE(HTTP)[[[400]]]] を返す方が良さそうに思えます。 [53] [[メッセージ]]は、[RUBYB[[[不完全]]]@en[incomplete]]なことがあります。詳しくは[[不完全メッセージ]]を参照してください。 [59] [[HTTP/1.0]] [[要求]]に対して [[HTTP/0.9]] [[応答]]が返された場合、 [[payload body]] の先頭が[[状態行]]のような文字列の時、 [[HTTP/1.0]] [[応答]]と誤認されることとなります。しかし [[HTTP/0.9]] [[鯖]]のほとんどは [CODE(MIME)@en[[[text/html]]]] なので、そのようなことはあまりないとされています [SRC[>>58]]。 ;; [[HTTP/0.9]] も参照。 [93] [[ヘッダー部]]が不完全な場合 ([[状態行]]の途中で終わっていた場合、 [[ヘッダー]]の後に[[改行]]がない場合、 [[ヘッダー]]の後の[[空行]]がない場合) には、[[接続]]が閉じられたところまでについて通常通り処理が行われるようです。ただし、 [[Firefox]] は[[状態行]]の[[改行]]がなく終わっている時は、[[ネットワークエラー]]とみなします ([[IE]] と [[Chrome]] はエラーにしません)。 [[ヘッダー]]が[[改行]]で終わっていないと、 [[Firefox]] は[[ネットワークエラー]]とみなし、 [[IE]] はその前の行までだけ処理します ([[Chrome]] はその[[ヘッダー]]まで含めて処理します)。 [TIME[2015-08-12T14:32:47.700Z]] [95] [[HTTPS]] の場合、 [[Chrome]] は[[ヘッダー部]]の途中で接続が閉じられると[[ネットワークエラー]]にします。 [[Firefox]] と [[IE]] は [[HTTP]] と同じくエラーにはしません。 [TIME[2015-09-12T14:26:03.400Z]] [105] [[Chrome]] も [[Firefox]] も、[[ヘッダー部]]の途中での [CODE[RST]] は[[ネットワークエラー]]とします。 [TIME[2016-07-17T12:51:02.200Z]] [106] [[Apache]] は[[要求本体]]が [CODE(HTTP)@en[Content-Length:]] に満たずに[[要求]]が閉じられると、 [CODE[400]] [[応答]]を返します。 [[nginx]] は通常通り処理を続けます。 [TIME[2016-09-09T09:14:41.400Z]] [107] [[nginx]] は継続行の処理がおかしく、ネットワークからのデータの到着のタイミングによっても結果が変わったりするようです。 [TIME[2016-09-10T13:07:19.500Z]] [108] (標準設定では) [[Apache]] も [[nginx]] も、[[ヘッダー部]]の各行は[[改行]]を含めて [N[8192]] [[バイト]]以下でなければ [CODE[400]] [[応答]]を返します。 [[Apache]] は継続行を連結して、[[ヘッダー名]]、[CODE[:]]、[[ヘッダー値]]、[[改行]]で [N[8192]] [[バイト]]以下でなければ [CODE[400]] [[応答]]を返します。 [[nginx]] は継続行を含めた検査を行わないように見えます。 [TIME[2016-09-11T06:41:34.000Z]] [109] [[Apache]] は[[要求ヘッダー]]を [N[100]] 個まで受け付け、それを超えると [CODE[400]] [[応答]]を返します。 [[nginx]] は [N[8438]] 個まで受け付け、それを超えると [CODE[400]] [[応答]]を返します。 [TIME[2016-09-11T06:59:19.700Z]] ** 改行 [33] [[HTTPメッセージ]]のうち、[[メッセージ本体]]よりも前の部分で区切りに使われる[[改行]]は、 [[CRLF]] です。 [[CR]] 単体や [[LF]] 単体ではありません。 [515] [[開始行]]や[[ヘッダー]]の後の[[改行]]である [[CRLF]] について、 [[LF]] を[[改行]]とみなし、直前に [[CR]] があれば無視することとしても構いません [SRC[>>514]]。 [92] [[nginx]] も [[Apache]] も、[[LF]] を[[改行]]とみなし、直前の [[CR]] を無視するようです。 [TIME[2015-06-14T10:26:26.300Z]] - [1] [[HTTP]] メッセージの頭の改行は [[CRLF]] で'''なければなりません'''が、 [CODE[Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS)]] というサーバーは [CODE[LF]] で出力します。 Mozilla や WinIE を含めた多くの [[UA]] はこれでも扱えるようですが、問題が出ることもあるみたいです。 - [2] >>1 例えば: ''Libraries of Kanazawa City'' - [3] >>1-2 互換モードを作って対応するとしたら、 [[HTTP]] [[RFC]]s によると応答の最初の行には単独の [[CR]], [[LF]] が含まれることはありませんから、もし出現したら buggy UA という方向で... [4] [[W3C]] の古い記述 (''Note: Client tolerance of bad HTTP servers'' ) は、クライアントは改行を [[LF]] と考えて、その前の [[CR]] を無視しなさい、と言っています。まあ [HTTP92] でも改行は [[CRLF]] と規定しているのですが... [5] >>4 もっと昔の TimBL が (たぶん) 最初に書いた仕様書には LF で、 CR を無視と書いてありましたです。 [6] もっとも、 >>5 は今で言う [[HTTP/0.9]] の話なので、影響するのは要求の最初の行の末だけです。 [94] herokuapp.com のサーバー ([[Cowboy]]?) は [[LF]] のみの要求を正しく扱えず、 [CODE(HTTP)[[[505]]]] [[応答]]を返します。 [TIME[2015-09-06T15:41:22.900Z]] * バイナリー形式メッセージ (HTTP/2) [67] [[メッセージ]]は、同一[[ストリーム]]中の[[フレーム]]の列として表されます。 [68] [[HTTPメッセージ]]は、次のもので構成されます [SRC[>>66]]。 [FIG(list)[ = [69] [[応答]]の場合、0個[[以上]]の [CODE(HTTP)[[[1xx]]]] [[応答]]: == [70] [CODE[[[HEADERS]]]] [[フレーム]] == [71] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]] = [72] [[メッセージ]]の[[ヘッダー]] == [73] [CODE[[[HEADERS]]]] [[フレーム]] == [74] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]] = [75] [[payload body]] == [76] 0個[[以上]]の [CODE[[[DATA]]]] [[フレーム]] = [77] [[trailer]] (省略可能) == [78] [CODE[[[HEADERS]]]] [[フレーム]] == [79] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]] ]FIG] ;; [80] [[HTTP/1.1]] [[以下]]とは違って、 [CODE(HTTP)[[[1xx]]]] [[応答]]が[[メッセージ]]内に入れ子に含まれる定義になっています。 ;; [89] [[サーバープッシュ]]の[[約束要求]]では、 [CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]]のかわりに [CODE(HTTP)@en[[[PUSH_PROMISE]]]] [[フレーム]]を使います。 [CODE(HTTP)@en[[[PUSH_PROMISE]]]] [[フレーム]]とそれに続く [CODE(HTTP)@en[[[CONTINUATION]]]] [[フレーム]]は、[[親ストリーム]]で送信されます。 [83] [CODE[[[HEADERS]]]] [[フレーム]]と [CODE[[[CONTINUATION]]]] [[フレーム]]の間や [CODE[[[CONTINUATION]]]] [[フレーム]]間に、他の[[フレーム]]があっては[['''なりません''']] [SRC[>>66]]。 [81] 最後の [CODE[[[HEADERS]]]] か [CODE[[[DATA]]]] の[[フレーム]]は、 [CODE[[[END_STREAM]]]] フラグが設定されます [SRC[>>66]]。 ;; [82] [CODE[[[CONTINUATION]]]] [[フレーム]]は [CODE[[[END_STREAM]]]] [[フレーム]]が存在せず、その直前の [CODE[[[HEADERS]]]] [[フレーム]]にかわりに設定されます。 [88] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]が存在しない場合、 [[ヘッダーリスト]]が2つ連続することになります。 [99] [CODE(HTTP)[[[1xx]]]] [[ヘッダー]]の後 [CODE[[[DATA]]]] を受信したらどうするべきかは定かではありません。 [100] [[Chrome]] は [CODE[[[200]]]] として扱うようです。 (逆に仕様通り [CODE[[[1xx]]]] [[ヘッダー]]の後に次の [CODE[[[HEADERS]]]] が現れると[[ストリームエラー]] [CODE[[[PROTOCOL_ERROR]]]] とします。) [[Firefox]] は [CODE[[[DATA]]]] [[フレーム]]を受信したら接続を閉じます。 [TIME[2015-10-11T10:01:10.700Z]] [90] [[payload body]] を持たない種別の[[メッセージ]]で [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]が存在する場合や、 [[payload body]] を持つ種別の[[メッセージ]]で [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]が存在しない場合にどうなるのかは謎です。 ;; [CODE(HTTP)@en[[[Content-Length]]]] の項も参照。 [101] [[Chrome]] も [[Firefox]] も、長さ0の [CODE[[[DATA]]]] はエラーとはしません。 [[Chrome]] は長さが非0でもエラーにせず、 [[XHR]] からアクセスできます。 [[Firefox]] は長さが非0だと[[ストリームエラー]] [CODE[[[CANCEL]]]] とします。[TIME[2015-10-11T10:08:32.400Z]] [103] [[Chrome]] は [[trailer]] に対応していないようで、 [[ストリームエラー]] [CODE[[[PROTOCOL_ERROR]]]] とします。 [TIME[2015-10-11T10:15:49.200Z]] [84] [[trailer]] の [[header block]] に [CODE[[[END_STREAM]]]] が設定されて[[ストリーム]]が閉じられなかったとしても、その後の [[header block]] は本[[メッセージ]]の一部ではありません [SRC[>>66]]。 [85] 最終的な[[状態符号]]を受信した後に [CODE[[[END_STREAM]]]] が設定されていない [CODE[[[HEADERS]]]] [[フレーム]]を受信したら、そのメッセージは[[奇形]]として扱わなければ[['''なりません''']] [SRC[>>66]]。 [102] [[Firefox]] はその場合[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]] とするようです。 [TIME[2015-10-11T10:14:49.200Z]] [104] [[Chrome]] も [[Firefox]] も、 [CODE[[[END_STREAM]]]] より前に [CODE[[[GOAWAY]]]] を受信しても、エラーとはしないで接続を閉じる ([[Firefox]] は [CODE[[[NO_ERROR]]]] の [CODE[[[GOAWAY]]]] を送信して閉じる) ようです。[[要求]]に対する[[応答]]は[[ネットワークエラー]]とします。 [TIME[2015-10-12T03:57:40.200Z]] [98] [[クライアント]]が[[要求]]を送信していない[[ストリーム]]で[[サーバー]]から [CODE[[[HEADERS]]]] を受信した時どうしたらいいのかは定かではありません。 [96] [[要求]]を送信していない[[ストリーム]]で [CODE[[[HEADERS]]]] を受信した時、 [[Chrome]] も [[Firefox]] も[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]] とし、送信中の[[要求]]については[[ネットワークエラー]]とするようです。 [TIME[2015-10-03T12:00:02.900Z]] [86] [[ストリーム]]の状態遷移の項も参照。 [87] [[奇形]]の項も参照。 * 文脈 [2053] [[メッセージ]]には[[要求メッセージ]]と[[応答メッセージ]]があり、それぞれ定義されている文脈で用いられます。 (それぞれの項と[[HTTP接続]]の項を参照してください。) [2054] [[メッセージ]]の一部又は全部のデータが送信されるタイミングについては、 [[HTTP接続]]の項を参照してください。 * 適合性 [16] [[送信者]]は、 [[ABNF]] [[生成規則]]により定義される[[文法]]に[[一致]]しない[[プロトコル要素]]を[[生成]]しては[['''なりません''']] [SRC[>>13]]。 ;; [50] [[ABNF]] [[生成規則]]の中には [CODE(ABNF)@en[[[obs-]]]] から始まるものがありますが、 [[RFC 5322]] とは違って [CODE(ABNF)@en[[[obs-]]]] から始まるとしてもただちに[[不適合]]になるわけではないようです。個別に不適合と規定されているものもあれば、何も言及がないものもあります。 [17] [[送信者]]は、[[送信者]]の役割に応じて、その[[役割]]の[[送信者]]が用いることを認められていない[[プロトコル要素]]や構文上の選択肢を用いては[['''なりません''']] [SRC[>>13]]。 [15] [[送信者]]は、[[偽]]であるとわかっていることを表している[[プロトコル要素]]を[[生成]]しては[['''なりません''']] [SRC[>>13]]。 [18] [[受信者]]は、その役割に適用され、 [[ABNF]] [[生成規則]]により定義される[[文法]]に[[一致]]するような値を[[構文解析]]することができなければ[['''なりません''']] [SRC[>>13]]。 [EG[ [19] すべての[[受信者]]がすべての[[プロトコル要素]]の[[構文解析]]を義務付けられているわけではありません。 [[串]]など[[メッセージ]]を[[転送]]する[[中間器]]は、[[ヘッダー]]一般の[[構文解析]]を行って名前と値の組として認識はするでしょうが、個々の値まで更に[[構文解析]]はしないで[[転送]]してしまいます。 ]EG] [23] [[受信者]]は、受信した[[プロトコル要素]]を適当な[[仕様書]]に従い解釈しなければ[['''なりません''']]。 [SRC[>>13]] [24] ただし[[受信者]]が (経験や設定により) [[送信者]]が誤って実装していると判定できるときは、この限りではありません。 [SRC[>>13]] [EG[ [25] 例えば、ある実装が特定の[[内容符号化]]の実装を誤っているとわかっており、 [CODE(HTTP)@en[[[User-Agent:]]]] から[[受信者]]がその実装であると推測できるときは、 [CODE(HTTP)@en[[[Accept-Encoding:]]]] を無視することができます。 [SRC[>>13]] ]EG] [26] [[HTTPのエラー処理]]も参照してください。 * 長さの制限 [20] ほとんどの[[プロトコル要素]]には特定の長さの制限は設けられていません。これは、利用される文脈や実装の目的により適切な長さが様々であるためとされています。 [SRC[>>13]] [21] [[受信者]]は少なくても自身が同じ[[プロトコル要素]]で生成し得る値と同じ長さは[[構文解析]]して処理できなければ[['''なりません''']] [SRC[>>13]]。 [EG[ [22] 例えばとても長い [[URL]] を出版する[[起源鯖]]は、それを[[要求URL]] として受け取って処理できる必要があります [SRC[>>13]]。 ]EG] * MIME 型 [519] テキスト形式の[[HTTPメッセージ]]に完全に対応する[[MIME型]]はありませんが、近い型は2つあります。 [520] [CODE(MIME)@en[[[application/http]]]] は、[[要求メッセージ]]の列、または[[応答メッセージ]]の列を表します。 ;; 詳しくは [CODE(MIME)@en[[[application/http]]]] を参照してください。 [521] [DFN[[CODE(MIME)@en[[[message/http]]]]]] は、 [[HTTPメッセージ]]1つを表す[[MIME型]]ですが、 [[MIME]] の [CODE(MIME)@en[[[message/*]]]] の制限が課される他、いくつかの要件が本来の[[HTTPメッセージ]]と異なっています。 [91] [[HTTP/2]] を扱えるのかは不明です。 ** 文脈 [528] [CODE(MIME)@en[[[message/http]]]] は [CODE(HTTP)@en[[[TRACE]]]] [[要求]]への[[応答]]として使われます [SRC[>>2052]]。 ;; [54] [[S-HTTP]] でも [CODE(MIME)@en[[[message/http]]]] を使うと規定されていました [SRC[>>60]] が、 [[S-HTTP]] 自体が普及しませんでした。 [REFS[ - [60] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ([TIME[2014-11-09 14:12:37 +09:00]] 版) ]REFS] ** 引数 [529] [CODE(MIME)@en[[[message/http]]]] には省略可能な[[引数]]が2つ定義されています [SRC[>>517]]。 [FIG(list)[ - [CODE(MIME)@en[[[version]]]] - [CODE(MIME)@en[[[msgtype]]]] ]FIG] ** CTE [526] [CODE(MIME)@en[[[message/http]]]] の [[CTE]] としては、 [CODE(MIME)@en[[[7bit]]]], [CODE(MIME)@en[[[8bit]]]], [CODE(MIME)@en[[[binary]]]] だけが認められます [SRC[>>517]]。 ;; [527] [[RFC 5335]] によりこの制限は [CODE(MIME)@en[[[message/*]]]] 一般には撤廃されていますが、 [[RFC 7230]] でも [CODE(MIME)@en[[[message/http]]]] に対しては引き続き課されているようです。 ** 処理モデル [51] [CODE(MIME)@en[[[message/http]]]] をどのように処理するべきかは規定されていません。唯一使われる場面が [CODE(HTTP)@en[[[TRACE]]]] [[要求]]に対する[[応答]]ですが、この[[メソッド]]も[[デバッグ]]用だからか特に処理は規定されていません。 ** 本体 [52] [[本体]]は、 [[HTTPメッセージ]]です。 [524] [CODE(MIME)@en[[[message/http]]]] の[[HTTPメッセージ]]は、 [[行長]]に関する [[MIME]] の制限に従う必要があります [SRC[>>517]]。 ;; [525] どの制限が不明です。 [[電子メール]]など[[MIME]]を使うプロトコルではなく、 [[MIME]]の側に [CODE(MIME)@en[[[message/*]]]] や[[本体部分]]の[[行長]]宣言ってあるのでしょうか? [530] [CODE(MIME)@en[[[message/http]]]] の[[HTTPメッセージ]]に関しては、 [[折り畳み]]の禁止に関する制約が緩和されます。詳しくは[[行折り畳み]]を参照してください。 ;; [531] なぜ敢えて例外規定を設けてまで、どれだけ実態があるかわからない [CODE(MIME)@en[[[message/http]]]] による利用を定義しているのか謎です。。。 [[電子メール]]での転送を想定しているのかもしれませんが、唯一の用法である [CODE(HTTP)@en[[[TRACE]]]] は[[電子メール]]ではありません。 ** 関連 [522] [[HTTPメッセージ]]と [[RFC 822]] [[メッセージ]]の類似性から、必然的に [CODE(MIME)@en[[[message/http]]]] と [CODE(MIME)@en[[[message/rfc822]]]] はよく似ています。 [523] 一般に [[HTTP]] [[メッセージ]]の [[CTE]] は [CODE(MIME)@en[[[binary]]]] です。[CODE(MIME)@en[[[7bit]]]] や [CODE(MIME)@en[[[8bit]]]] の旧来の [[SMTP]] や [[NNTP]] の如き[[転送路]]では転送することができません。他の[[MIME型]]であれば [[Base64]] や [[Quoted-Printable]] のような [[CTE]] で[[符号化]]するべきところですが、 [[MIME]] の規定により、 [CODE(MIME)@en[[[message/[VAR[*]]]]]] の[[符号化]]は一切禁止されているので、仕様に従いつつ転送する術はありません。 [CODE(MIME)@en[[[message/http]]]] の代わりに [CODE(MIME)@en[[[application/http]]]] として[[札付け]]することでこの制約を回避できます。 * API [FIG(short list)[ [110] [[HTTPメッセージ]] [[API]] - [[CGI]] - [[PSR-7]] - [CODE[Request]] / [CODE[Response]] ]FIG] * 歴史 [FIG(quote)[ [FIGCAPTION[ [14] [[HTTP]] ([[RFC 1945]] 1.2, [[RFC 2068]] 1.3, [[RFC 2616]] 1.3) ]FIGCAPTION] > :message: The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in [DEL[[INS[{1945]]] Section]] [INS[section]] 4 and transmitted via the connection. :メッセージ: HTTP 通信の基本単位で、第4章で定義する構文に一致する構造化オクテット列から成り、 [[接続]]を介して転送される。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [10] RFC 1945 4.1 Message Types ]FIGCAPTION] HTTP messages consist of requests from client to server and responses from server to client. HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答から構成されます。 [PRE[ HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response ]PRE] [PRE[ Full-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF). ]PRE] Full-Request と Full-Response は実体の転送に RFC 822 の一般メッセージ形式を使います。両メッセージは省略可能な頭欄 (「頭達」とも呼ばれる) と実体本文を含んでも構いません。実体本文は頭達と空行 (つまり CRLF の前に何も無い行) で区切ります。 [PRE[ Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 ]PRE] [PRE[ Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 ]PRE] Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET). Simple-Request と Simple-Response はいかなる頭情報の使用も認められませんし、単一要求方式 (GET) に制限されます。 [PRE[ Simple-Request = "GET" SP Request-URI CRLF ]PRE] [PRE[ Simple-Response = [ Entity-Body ] ]PRE] Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity. Simple-Request 形式の使用は非推奨です。この形式では返される実体の媒体型を識別できないからです。 ]FIG] [FIG[ [FIGCAPTION[ [11] RFC 2616 4.1 Message Types ]FIGCAPTION] HTTP messages consist of requests from client to server and responses from server to client. HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答で構成されます。 [PRE[ HTTP-message = Request | Response ; HTTP/1.1 messages ]PRE] [PRE[ Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body. ]PRE] Request, Response 両メッセージは実体 (メッセージの弾頭) の転送に RFC 822 の一般メッセージ形式を使います。両メッセージ型は star-line, 0個以上の頭欄 (「頭達」とも呼ばれる), 頭欄の終わりを示す空行 (つまり CRLF の前に何も無い行), それとあれば message-body から構成されます。 [PRE[ generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line ]PRE] [PRE[ In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. ]PRE] 頑強性の点から、サーバーは Request-Line が来るはずのところで受け取った空行を無視するべきです。他の言葉でいえば、サーバーがメッセージの始めのプロトコル列を読んで最初に CRLF を受け取ったなら、その CRLF は無視するべきです。 [PRE[ Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF. ]PRE] イかれた HTTP/1.0 の顧客実装は余計な CRLF 達を POST 要求の後に生成します。 BNF で明示的に禁止されていることを繰り返しますが、 HTTP/1.1 顧客は要求の前や後に余計な CRLF をつけては'''いけません'''。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [518] RFC 1945 (HTTP/1.0) A.; RFC 2068 (HTTP/1.1) 19.1 Internet Media Type message/http, RFC 2616 (HTTP/1.1) 19.1 Internet Media Type message/http and application/http ]FIGCAPTION] > In addition to defining the [DEL[[INS[{1945}]] HTTP/1.0]] [INS[HTTP/1.1]] protocol, this document serves as the specification for the Internet media type "message/http" [INS[[INS[{2616}]] and "application/http"]]. [INS[[INS[{2616}]] The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).]] The following is to be registered with IANA [DEL[[INS[{1945}]] [13] ]] [INS[[INS[{2616}]] [17] ]]. この文書は、 HTTP プロトコルを定義するのに加えて、インターネット[[媒体型]] [CODE(MIME)[message/http]] [INS[および [CODE(MIME)[[[application/http]]]]]] の仕様を給仕します。[INS[[CODE(MIME)[message/http]] 型は、単一の HTTP 要求メッセージまたは応答メッセージを、すべての [CODE(MIME)[message]] 型についての行長と符号化に関する MIME の制限に従うものとして囲むために使うことができます。 [CODE(HTTP)[application/http]] 型は、一つ以上の HTTP 要求メッセージ群または応答メッセージ群 (非混合。) のパイプ線を囲むために使うことができます。]] 次は、 IANA に登録されます。 > :Media Type name:message :Media subtype name:http :Required parameters:none :Optional parameters:version, msgtype > :version:The HTTP-Version number of the enclosed message (e.g., [DEL[[INS[{1945}]] "1.0"]] [INS["1.1"]]). If not present, the version can be determined from the first line of the body. 囲まれたメッセージの [CODE(ABNF)[[[HTTP-Version]]]] 番号 (例えば [CODE(HTTP)[1.0]] や [CODE(HTTP)[1.1]]。) 存在しなければ、版は[[本体]]の最初の行から決定できます。 > :msgtype:The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. メッセージ型 — [CODE(MIME)[request]] 又は [CODE(MIME)[response]]。存在しなければ、型は本体の最初の行から決定できます。 > :Encoding considerations:only "7bit", "8bit", or "binary" are permitted :Security considerations:none [INS[ > [INS[{2616}]] :Media Type name:application :Media subtype name:http :Required parameters:none :Optional parameters:version, msgtype > :version:The HTTP-Version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body. 囲まれたメッセージの [CODE(ABNF)[HTTP-Version]] 番号 (例えば [CODE(HTTP)[1.1]]。) 存在しなければ、版は本体の最初の行から決定できます。 > :msgtype:The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. メッセージ型 — [CODE(MIME)[request]] 又は [CODE(MIME)[response]]。存在しなければ、型は本体の最初の行から決定できます。 > :Encoding considerations:HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via E-mail. この型で囲まれた HTTP メッセージは [CODE(MIME)[[[binary]]]] 書式です。 [[電子メイル]]を介して転送するときには適切な [CODE(MIME)[[[Content-Transfer-Encoding]]]] が必要です。 > :Security considerations:none ]INS] ]FIG] [FIG(quote)[ [FIGCAPTION[ [2048] RFC 1945 (HTTP/1.0) 4.; RFC 2068・2616 (HTTP/1.1) 4 HTTP Message ]FIGCAPTION] *4.1 Message Types > HTTP messages consist of requests from client to server and responses from server to client. [DFN[HTTP メッセージ]]は、[[クライアント]]から[[サーバー]]への[[要求]]と[[サーバー]]から[[クライアント]]への[[応答]]から成ります。 > [DEL[ - [PRE[ HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response ]PRE] ]DEL] [INS[ - HTTP-message = Request | Response ; HTTP/1.1 messages ]INS] > [DEL[Full-Request]] [INS[Request (section 5)]] and [DEL[Full-Response]] [INS[Response (section 6) messages]] use the generic message format of RFC 822 [DEL[ [7] ]] [INS[ [9] ]] for transferring entities [INS[(the payload of the message)]]. [DEL[Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).]] [INS[Both types of message consist of a start-line, [DEL[one]] [INS[zero]] or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and [DEL[an optional]] [INS[possibly a]] message-body.]] (完全)要求メッセージと(完全)応答メッセージは、[[実体]] [INS[(メッセージの積荷)]] を転送するために [[RFC822]] の一般メッセージ書式を使います。メッセージのどちらの型も、 [CODE(ABNF)[start-line]] (開始行)、[DEL[一つ]][INS[零個]]以上の[[頭欄]] ([CODE[[[頭]]]]とも)、頭欄並びの終わりを示す空行 (つまり [[CRLF]] の前に何も無い行)、それにもしかすると [CODE(ABNF)[[[message-body]]]] (メッセージ本体) から成ります。 > [DEL[ - [PRE[ Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 ]PRE] - [PRE[ Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 ]PRE] ]DEL] > [INS[ - [PRE[ generic-message = start-line [DEL[*message-header]] [INS[*(message-header CRLF)]] CRLF [ message-body ] ]PRE] - start-line = Request-Line | Status-Line ]INS] [DEL[ > Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET). [CODE(ABNF)[Simple-Request]] (単純要求) と [CODE(ABNF)[Simple-Response]] は頭情報の使用を認めず、要求方式も1つ ([CODE(HTTP)[[[GET]]]]) に限定します。 > - Simple-Request = "GET" SP Request-URI CRLF > - Simple-Response = [ Entity-Body ] > Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity. [CODE(HTTP)[Simple-Request]] 書式は、サーバーから返される実体の[[媒体型]]を識別することができませんから、その使用は非推奨とします。 ]DEL] [INS[ > In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. 頑強性の観点から、サーバーは [CODE(ABNF)[[[Request-Line]]]] が期待されるところで受取った空行(並び)を無視する'''べきです'''。言い換えると、サーバーがメッセージのはじめでプロトコル流を読んでいて最初に CRLF を受取ったら、この CRLF は無視するべきです。 > [DEL[Note: certain]] [INS[Certain]] buggy HTTP/1.0 client implementations generate [DEL[an]] extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client [DEL[must not]] [INS[MUST NOT]] preface or follow a request with an extra CRLF. ある蝕まれた HTTP/1.0 クライアント実装は [CODE(HTTP)[[[POST]]]] 要求の後に余分な CRLF を生成します。 BNF で陽に禁止されていることを繰り返しますが、 HTTP/1.1 クライアントは要求の前や後に余分な CRLF を入れては'''いけません'''。 ]INS] [INS[ 注: 追加・削除は 1945→2068 のもの。追加中の追加・削除は 2068→2616 のもの。 ]INS] * 4.2 Message Headers →[CODE(WikiPage)[[[HTTP//頭欄]]]] *RFC 2068・2616 4.3 Message Body →[CODE(WikiPage)[[[message-body]]]] *RFC 2068・2616 4.4 Message Length →[CODE(WikiPage)[[[Content-Length]]]] *RFC 1945 4.3; RFC 2068・2616 4.5 General Header Fields →[CODE(WikiPage)[[[一般頭欄]]]] ]FIG] [FIG(quote)[ [FIGCAPTION[ [2049] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 2.2 Basic Rules ]FIGCAPTION] > The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by [DEL[[INS[{1945}]] [17] ]] [INS[[INS[{2068,2616}]] ANSI X3.4-1986 [21] ]]. 次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。 > -OCTET = -CHAR = -UPALPHA = -LOALPHA = -ALPHA = UPALPHA | LOALPHA -DIGIT = -CTL = -CR = -LF = -SP = -HT = -<"> = > [DEL[HTTP/1.0]] [INS[HTTP/1.1]] defines the [DEL[[INS[{1945}]] octet]] sequence CR LF as the end-of-line marker for all protocol elements except the [DEL[[INS[{1945}]] Entity-Body]] [INS[entity-body]] (see [DEL[[INS[{1945}]] Appendix B]] [INS[appendix 19.3]] for tolerant applications). The end-of-line marker within an [DEL[[INS[{1945}]] Entity-Body]] [INS[entity-body]] is defined by its associated media type, as described in [DEL[[INS[{1945}]] Section 3.6]] [INS[section 3.7]]. HTTP は実体本体を除くすべてのプロトコル要素で列 CR LF を行末の[RUBY[印] [しるし]]と定義します。実体本体中の行末の印はその関連付けられた[[媒体型]]により定義されます。 > -CRLF = CR LF > [DEL[HTTP/1.0]] [INS[HTTP/1.1]] [DEL[[INS[{1945,2068}]] headers]] [INS[[INS[{2616}]] header field values]] [DEL[[INS[{1945}]] may]] [INS[can]] be folded onto multiple lines if [DEL[[INS[{1945}]] each]] [INS[the]] continuation line begins with a space or horizontal tab. All linear [DEL[[INS[{1945}]] whitespace]] [INS[white space]], including folding, has the same semantics as SP. [INS[[INS[{2616}]] A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.]] HTTP 頭[INS[欄値]]は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。すべての線形空白は、折畳みも含み、 [CODE(ABNF)[SP]] と同じ意味を持ちます。[INS[受信者は、欄値を解釈したり[[下流]]にメッセージを転送する前に任意の線形空白を単一の [CODE(ABNF)[SP]] に置換しても'''構いません'''。]] > -LWS = [CRLF] 1*( SP | HT ) [DEL[ >[INS[{1945}]] However, folding of header lines is not expected by some applications, and should not be generated by HTTP/1.0 applications. しかし、頭行の折畳みを予期していない応用もありますので、 HTTP/1.0 応用は生成するべきではありません。 ]DEL] > 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 [DEL[[INS[{1945,2068}]] may]] [INS[[INS[{2616}]] MAY]] contain [DEL[[INS[{1945}]] octets]] [INS[characters]] from character sets other than [DEL[[INS[{1945}]] US-ASCII]] [INS[[INS[{2068,2616}]] [DEL[ISO 8859-1]] [INS[ISO-8859-1]] [22] only when encoded according to the rules of RFC [DEL[1522]] [INS[2047]] [14] ]]. [CODE(ABNF)[TEXT]] 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。 [CODE(ABNF)[*TEXT]] の語は [DEL[US-ASCII]] [INS[RFC 2047 の規則に従って符号化するときのみ ISO-8859-1]] 以外の文字集合の[DEL[オクテット]][INS[文字]]を含んでも'''構いません'''。 > -TEXT = [DEL[ >[INS[{1945}]] Recipients of header field TEXT containing octets outside the US-ASCII character set may assume that they represent ISO-8859-1 characters. US-ASCII 文字集合の外のオクテットを含んだ頭欄 [CODE(ABNF)[TEXT]] の受信者は、それが ISO-8859-1 文字を表現するものと仮定しても構いません。 ]DEL] [INS[ >[INS[{2616}]] A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value. [CODE(ABNF)[CRLF]] は、 [CODE(ABNF)[TEXT]] の定義の中では、頭欄継続の一部としてのみ認められています。折畳み [CODE(ABNF)[LWS]] は [CODE(ABNF)[TEXT]] 値の解釈の前に単一の [CODE(ABNF)[SP]] に置換されることを意図定しています。 ]INS] > Hexadecimal numeric characters are used in several protocol elements. 十六進数文字は幾つかのプロトコル要素で使います。 > -HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT > Many [DEL[HTTP/1.0]] [INS[HTTP/1.1]] header field values consist of words separated by LWS or special characters. These special characters [DEL[[INS[{1945}]] must]] [INS[MUST]] be in a quoted string to be used within a parameter value [INS[[INS[{2616}]] (as defined in section 3.6)]]. 多くの HTTP 頭欄値は、 [CODE(ABNF)[LWS]] または特殊文字で分離される語で構成されます。特殊文字は引数値中で使うためには引用文字列中にいれなければ'''なりません'''。 [DEL[ >[INS[{1945}]] - word = token | quoted-string ]DEL] [DEL[ >[INS[{1945,2068}]] -token = 1* -tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT ]DEL] [INS[ >[INS[{2616}]] -token = 1* -separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT ]INS] > Comments [DEL[[INS[{1945}]] may]] [INS[can]] be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value. 注釈は、注釈文を括弧で囲むことで幾つかの HTTP 頭欄中に含めることができます。注釈は、欄値定義の一部に [CODE(ABNF)[comment]] を含んでいる欄でのみ認められます。他のすべての欄では、括弧は欄値の一部とみなされます。 > -[DEL[[INS[{1945,2068}]] comment = "(" *( ctext | comment ) ")"]] -[INS[[INS[{2616}]] comment = "(" *( ctext | quoted-pair | comment ) ")"]] -ctext = > A string of text is parsed as a single word if it is quoted using double-quote marks. 二重引用符を使って引用されている文字列は単一の語として解析します。 > -[DEL[[INS[{1945,2068}]] quoted-string = ( <"> *(qdtext) <"> )]] -[INS[[INS[{2616}]] quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )]] -[DEL[[INS[{1945}]] qdtext = and CTLs, but including LWS>]] -[INS[[INS[{2068,2616}]] qdtext = >]] [DEL[ >[INS[{1945}]] Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0. HTTP/1.0 では逆斜線 ([CODE(char)[\]]) 文字を使った単一文字引用は認められていません。 ]DEL] [INS[ >[INS[{2068,2616}]] The backslash character ("\") [DEL[may]] [INS[MAY]] be used as a single-character quoting mechanism only within quoted-string and comment constructs. 逆斜線文字 ([CODE(HTTP)[\]]) は、 [CODE(ABNF)[quoted-string]] 構造体および [CODE(ABNF)[comment]] 構造体の中でのみ、単一文字引用機構として使って'''構いません'''。 > - quoted-pair = "\" CHAR ]INS] ]FIG] [FIG(quote)[ [FIGCAPTION[ [2050] RFC 2326 (RTSP/1.0) 15 Syntax ]FIGCAPTION] > The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used in RFC 2068 [2]. *15.1 Base Syntax > OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA > DIGIT = CTL = CR = LF = > SP = HT = <"> = CRLF = CR LF LWS = [CRLF] 1*( SP | HT ) TEXT = tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT > token = 1* quoted-string = ( <"> *(qdtext) <"> ) qdtext = > quoted-pair = "\" CHAR > message-header = field-name ":" [ field-value ] CRLF field-name = token field-value = *( field-content | LWS ) field-content = > safe = "\$" | "-" | "_" | "." | "+" extra = "!" | "*" | "$'$" | "(" | ")" | "," > hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" escape = "\%" hex hex reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" > unreserved = alpha | digit | safe | extra xchar = unreserved | reserved | escape [INS[ 訳注 : 編集上の誤りっぽいところがありますが、原文通りにしておきます。 ]INS] ]FIG] [FIG(quote)[ [FIGCAPTION[ [2051] RFC 2543 C.1; RFC 3261 25.1 (SIP/2.0) Basic Rules ]FIGCAPTION] > The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986. 次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。 > [DEL[ - OCTET = - CHAR = - upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" - lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" - alpha = lowalpha | upalpha - digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - alphanum = alpha | digit - CTL = - CR = %d13 ; US-ASCII CR, carriage return character - LF = %d10 ; US-ASCII LF, line feed character - SP = %d32 ; US-ASCII SP, space character - HT = %d09 ; US-ASCII HT, horizontal tab character - CRLF = CR LF ; typically the end of a line ]DEL] [INS[ - alphanum = ALPHA / DIGIT ]INS] [INS[ > The following are defined in RFC 2396 [12] for the SIP URI: Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include: 次は [[RFC2396]] で定義されており、 SIP URI で使います。幾つかの規則は RFC 2396 と違っていますが、 [[RFC2234]] に適合するために更新したものです。 ]INS] > [DEL[ - unreserved = alphanum | mark -mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" - escaped = "%" hex hex ]DEL] [INS[ - reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," - unreserved = alphanum / mark - mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" - escaped = "%" HEXDIG HEXDIG ]INS] > SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. [INS[This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators.]] SIP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。すべての線形空白は、折畳みも含み、 [CODE(ABNF)[SP]] と同じ意味を持ちます。受信者は、欄値を解釈したり[[下流]]にメッセージを転送する前に任意の線形空白を単一の [CODE(ABNF)[SP]] に置換しても'''構いません'''。[INS[これは RFC 2616 で説明されている HTTP/1.1 の場合と全く同じようになることを意図しています。 [CODE(ABNF)[SWS]] 構造体は線形空白が省略可能である時、通常は字句と分離子の間で使います。]] > -[DEL[ LWS = [CRLF] 1*( SP | HT ) ; linear whitespace]] -[INS[ LWS = [*WSP CRLF] 1*WSP ; linear whitespace]] -[INS[ SWS = [LWS] ; sep whitespace]] [INS[ > To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct. 頭名を残りの値と分離するためにコロンを使いますが、これは上の規則により前に空白を求めるものの改行は認めず、後には空白を改行も含めて認めます。 [CODE(ABNF)[HCOLON]] はこの構造体を定義します。 > - HCOLON = *( SP / HTAB ) ":" SWS ]INS] > The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 [DEL[character set (RFC 2279 [21])]] [INS[charset (RFC 2279 [7])]]. [INS[The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. ]] In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set. [CODE(ABNF)[TEXT-UTF8]] 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。 [CODE(ABNF)[*TEXT-UTF8]] の語は UTF-8 charset の文字だけを含めます。[INS[[CODE(ABNF)[TEXT-UTF8-TRIM]] 規則は引用文字列ではなく、最初と最後の [CODE(ABNF)[LWS]] が意味を持たない記述的欄内容に使用します。]] この点では、 SIP は ISO 8859‐1 を使用する HTTP と異なります。 > [DEL[ - TEXT-UTF8 = ]DEL] [INS[ - TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) - TEXT-UTF8char = %x21-7E / UTF8-NONASCII - UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT - UTF8-CONT = %x80-BF ]DEL] > A CRLF is allowed in the definition of TEXT-UTF8[INS[-TRIM]] only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-UTF8[INS[-TRIM]] value. [CODE(ABNF)[CRLF]] は、 [CODE(ABNF)[TEXT-TRIM]] の定義の中では、頭欄継続の一部としてのみ認められています。折畳み [CODE(ABNF)[LWS]] は [CODE(ABNF)[TEXT-TRIM]] 値の解釈の前に単一の [CODE(ABNF)[SP]] に置換されることを意図定しています。 > Hexadecimal numeric characters are used in several protocol elements. [INS[Some elements (authentication) force hex alphas to be lower case.]] 十六進数文字は幾つかのプロトコル要素で使います。[INS[幾つかの要素 (認証) は十六進字母が小文字であることを強制します。]] > - [DEL[hex = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | digit]] - [INS[LHEX = DIGIT / %x61-66 ;lowercase a-f]] > Many SIP header field values consist of words separated by LWS or special characters. [INS[Unless otherwise stated, tokens are case-insensitive.]] These special characters MUST be in a quoted string to be used within a parameter value. [INS[The word construct is used in Call-ID to allow most separators to be used.]] 多くの SIP 頭欄値は、 [CODE(ABNF)[LWS]] または特殊文字で分離される語で構成されます。[INS[別途言及されていない限り、字句は大文字・小文字を区別します。]] 特殊文字は引数値中で使うためには引用文字列中にいれなければ'''なりません'''。 [INS[[CODE(ABNF)[word]] 構造体は [CODE(SIP)[[[Call-ID]]]] でほとんどの分離子を使用できるようにするために使います。]] > -[DEL[ token = 1*< any CHAR except CTL's or separators>]] -[INS[ token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )]] - [DEL[separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT]] - [INS[separators = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HTAB]] - [INS[word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" )]] [INS[ > When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters: 字句が使われる場合や分離子が要素間で使われる場合には、空白がしばしばその文字の前後に認められます。 > - STAR = SWS "*" SWS ; asterisk - SLASH = SWS "/" SWS ; slash - EQUAL = SWS "=" SWS ; equal - LPAREN = SWS "(" SWS ; left parenthesis - RPAREN = SWS ")" SWS ; right parenthesis - RAQUOT = ">" SWS ; right angle quote - LAQUOT = SWS "<"; left angle quote - COMMA = SWS "," SWS ; comma - SEMI = SWS ";" SWS ; semicolon - COLON = SWS ":" SWS ; colon - LDQUOT = SWS DQUOTE; open double quotation mark - RDQUOT = DQUOTE SWS ; close double quotation mark ]INS] > Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value. 注釈は、注釈文を括弧で囲むことで幾つかの SIP 頭欄中に含めることができます。注釈は、欄値定義の一部に [CODE(ABNF)[comment]] を含んでいる欄でのみ認められます。他のすべての欄では、括弧は欄値の一部とみなされます。 > -[DEL[ comment = "(" *(ctext | quoted-pair | comment) ")"]] -[INS[ comment = LPAREN *(ctext / quoted-pair / comment) RPAREN]] -[DEL[ ctext = < any TEXT-UTF8 excluding "(" and ")">]] -[INS[ ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS]] > [INS[ctext includes all chars except left and right parens and backslash.]] A string of text is parsed as a single word if it is quoted using double-quote marks. [INS[In quoted strings, quotation marks (") and backslashes (\) need to be escaped.]] ;[INS[[CODE(ABNF)[ctext]] は左右の括弧と逆斜線を除くすべての文字を含みます。]] 二重引用符を使って引用されている文字列は単一の語として解析します。[INS[引用文字列中では、引用符 ([CODE(SIP)["]]) と逆斜線 ([CODE(SIP)[\]]) は escape する必要があります。]] > -[DEL[ quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )]] -[INS[ quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE]] -[DEL[ qdtext = >]] -[INS[ qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII]] > The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. [INS[Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.]] 逆斜線文字 ([CODE(HTTP)[\]]) は、 [CODE(ABNF)[quoted-string]] 構造体および [CODE(ABNF)[comment]] 構造体の中でのみ、単一文字引用機構として使って'''構いません'''。[INS[HTTP/1.1 とは異なり、文字 [CODE(ABNF)[CR]] 及び [CODE(ABNF)[LF]] は行折畳みや頭分離との衝突を避けるためにこの機構を使って escape することはできません。]] > -[DEL[ quoted-pair = " \ " CHAR]] -[INS[ quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)]] ]FIG] [12] [CITE[Apache HTTP Server Project]] ( ([TIME[2011-05-28 00:58:55 +09:00]] 版)) [532] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ( ([TIME[2014-05-03 23:12:15 +09:00]] 版)) [2055] [CITE@en[RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)]] ( ([TIME[2014-09-22 20:05:44 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [63] [CITE@en[Final: OpenID Connect Core 1.0 incorporating errata set 1]] ([TIME[2014-11-09 04:00:29 +09:00]] 版) ]FIGCAPTION] > Message > Request or a response between an OpenID Relying Party and an OpenID Provider. ]FIG] [FIG(quote)[ [FIGCAPTION[ [64] [CITE@en[mod_proxy_http - Apache HTTP Server Version 2.4]] ([TIME[2015-01-18 02:21:01 +09:00]] 版) ]FIGCAPTION] > proxy-sendextracrlf > Causes proxy to send an extra CR-LF newline on the end of a request. This is a workaround for a bug in some browsers. ]FIG] [FIG(quote)[ [FIGCAPTION[ [97] [CITE@en[RFC 5989 - A SIP Event Package for Subscribing to Changes to an HTTP Resource]] ([TIME[2015-09-20 16:18:55 +09:00]] 版) ]FIGCAPTION] > By default, the message bodies of NOTIFY messages for the http- > monitor event package will be of content-type "message/http," as > defined in RFC 2616 '''['''2''']'''. ]FIG]