HTTP//メッセージ

メッセージ (HTTP)

[27] メッセージ (message) は、 HTTP における情報伝達の単位 (アプリケーション層パケット) です。

[28] メッセージには、要求メッセージ応答メッセージがあります。

仕様書

テキスト形式メッセージ (HTTP/0.9, HTTP/1.0, HTTP/1.1)

[65] HTTP/1.0HTTP/1.1 は、 RFC 822 に由来するテキスト形式のメッセージ構文を採用していました。 HTTP/0.9 はそれよりも更に単純な形式でした。

構文

[29] メッセージは、開始行ヘッダーメッセージ本体の3つの部分で構成されます >>30

[46] HTTP/0.9 応答以外のすべてのHTTPメッセージには、 開始行が存在します。

[31] ヘッダーは、任意の個数使用することができ、必ず直後に CRLF が来ます。 >>30 ただし HTTP/0.9 ではヘッダーを使うことができません。

[32] 開始行およびヘッダーメッセージ本体の間には、必ず1つ CRLF が来ます。 >>30 最後のヘッダーの後の CRLF (ヘッダーが無い場合は開始行の最後の CRLF) とあわせて、 CRLF CRLF と2回連続することになります。 なお HTTP/0.9 ではこの CRLF は存在しません。

[34] メッセージ本体は省略することもできます >>30HTTP/0.9 要求ではメッセージ本体を使えません。

[35] ヘッダーメッセージ本体は省略できますが、 いつでも省略できるわけではなく、他の色々な条件で制約されています。

[36] HTTP/1.x では、メッセージ本体がなくても、区切りの CRLF は必要です。

[47] HTTP/0.9 応答は、開始行ヘッダーがなく、全体がメッセージ本体となります。
  1. |
    1. =
      1. 開始行
      2. *
        1. ヘッダー
        2. CRLF
      3. CRLF
      4. ?
        1. メッセージ本体
    2. HTTP/0.9 要求
      1. 開始行
    3. HTTP/0.9 応答
      1. メッセージ本体

[62] SSDPHTTP/1.1 と同じメッセージの構文を採用しています >>61

構文解析

[42] HTTPメッセージストリームとして構文解析して漸進的処理に供したり、 下流転送したりできます。しかし、実装によっては転送するメッセージバッファリングしたり遅延させたりして調整したり何らかの処理を行ったりすることがありますから、 受信者は、メッセージ漸進的に受信できることに依存できません。 >>30

[43]HTTP 仕様書は言っていますが、実際にはクライアントの間の接続を維持し、 メッセージ本体中のデータを随時断続的に送信していくような使われ方がしばしばなされています。 メッセージをすべて読み終わるまで転送できないような中間器は、 Web互換ではありません。

[41] 受信者は、HTTPメッセージUS-ASCII超集合オクテット列として構文解析しなければなりません>>30

[37] 通常は HTTPメッセージを次のように構文解析します >>30

  1. [38] 開始行を読んで構造を解釈します。
  2. [39] 空行に達するまで各ヘッダーを読んで、 ヘッダー名ハッシュ表に入れます。
  3. [40] メッセージ本体があれば、メッセージ本体長分に達するか接続が閉じられるまでのオクテットストリームとして読みます。

[513] は、少なくても1つは要求行の前の CRLF を無視するべきです >>514

HTTP接続も参照。

[44] 送信者開始行と最初のヘッダーの間に空白送信してはなりません >>30受信者は、開始行ヘッダーの間に空白があれば、 メッセージ非妥当であるとして拒絶するか、 空白で始まるを消費して無視するかのいずれかとしなければなりません >>30

[45] 生成ではなく送信が禁止されているので、転送するだけの場合であっても、 空白をそのままにすることは禁止されています。

[48] メッセージ本体の項も参照してください。

[516] HTTP 要求メッセージのみを受け付けるは、 HTTPメッセージの文法に沿わないオクテット列を受け取った場合、 (他に規定がなければ) 400 応答を送るべきです >>514

[55] Apacheヘッダー部ヘッダーでないもの (: が含まれない) が混じっていると 400 を返します。 nginx は無視するようです。

[56] 400 を返す方が良さそうに思えます。

[53] メッセージは、不完全 (incomplete) なことがあります。 詳しくは不完全メッセージを参照してください。

[59] HTTP/1.0 要求に対して HTTP/0.9 応答が返された場合、 payload body の先頭が状態行のような文字列の時、 HTTP/1.0 応答と誤認されることとなります。しかし HTTP/0.9 のほとんどは text/html なので、 そのようなことはあまりないとされています >>58

HTTP/0.9 も参照。

[93] ヘッダー部が不完全な場合 (状態行の途中で終わっていた場合、 ヘッダーの後に改行がない場合、 ヘッダーの後の空行がない場合) には、接続が閉じられたところまでについて通常通り処理が行われるようです。 ただし、 Firefox状態行改行がなく終わっている時は、ネットワークエラーとみなします (IEChrome はエラーにしません)。 ヘッダー改行で終わっていないと、 Firefoxネットワークエラーとみなし、 IE はその前の行までだけ処理します (Chrome はそのヘッダーまで含めて処理します)。

[95] HTTPS の場合、 Chromeヘッダー部の途中で接続が閉じられるとネットワークエラーにします。 FirefoxIEHTTP と同じくエラーにはしません。

[105] ChromeFirefox も、ヘッダー部の途中での RSTネットワークエラーとします。

[106] Apache要求本体Content-Length: に満たずに要求が閉じられると、 400 応答を返します。 nginx は通常通り処理を続けます。

[107] nginx は継続行の処理がおかしく、ネットワークからのデータの到着のタイミングによっても結果が変わったりするようです。

[108] (標準設定では) Apachenginx も、ヘッダー部の各行は改行を含めて 8192 バイト以下でなければ 400 応答を返します。 Apache は継続行を連結して、ヘッダー名:ヘッダー値改行8192 バイト以下でなければ 400 応答を返します。 nginx は継続行を含めた検査を行わないように見えます。

[109] Apache要求ヘッダー100 個まで受け付け、それを超えると 400 応答を返します。 nginx8438 個まで受け付け、それを超えると 400 応答を返します。

改行

[33] HTTPメッセージのうち、メッセージ本体よりも前の部分で区切りに使われる改行は、 CRLF です。 CR 単体や LF 単体ではありません。

[515] 開始行ヘッダーの後の改行である CRLF について、 LF改行とみなし、直前に CR があれば無視することとしても構いません >>514

[92] nginxApache も、LF改行とみなし、直前の CR を無視するようです。

  • [1] HTTP メッセージの頭の改行は CRLFなければなりませんが、 Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS) というサーバーは LF で出力します。 Mozilla や WinIE を含めた多くの UA はこれでも扱えるようですが、問題が出ることもあるみたいです。
  • [2] >>1 例えば: Libraries of Kanazawa City http://www.lib.kanazawa.ishikawa.jp/
  • [3] >>1-2 互換モードを作って対応するとしたら、 HTTP RFCs によると応答の最初の行には単独の CR, LF が含まれることはありませんから、もし出現したら buggy UA という方向で...

[4] W3C の古い記述 (Note: Client tolerance of bad HTTP servers http://www.w3.org/Protocols/HTTP/OldServers.html) は、クライアントは改行を LF と考えて、その前の CR を無視しなさい、と言っています。

まあ [HTTP92] でも改行は CRLF と規定しているのですが...

[5] >>4 もっと昔の TimBL が (たぶん) 最初に書いた仕様書には LF で、 CR を無視と書いてありましたです。

[6] もっとも、 >>5 は今で言う HTTP/0.9 の話なので、影響するのは要求の最初の行の末だけです。

[94] herokuapp.com のサーバー (Cowboy?) は LF のみの要求を正しく扱えず、 505 応答を返します。

バイナリー形式メッセージ (HTTP/2)

[67] メッセージは、同一ストリーム中のフレームの列として表されます。

[68] HTTPメッセージは、次のもので構成されます >>66

  1. [69] 応答の場合、0個以上1xx 応答:
    1. [70] HEADERS フレーム
    2. [71] 0個以上CONTINUATION フレーム
  2. [72] メッセージヘッダー
    1. [73] HEADERS フレーム
    2. [74] 0個以上CONTINUATION フレーム
  3. [75] payload body
    1. [76] 0個以上DATA フレーム
  4. [77] trailer (省略可能)
    1. [78] HEADERS フレーム
    2. [79] 0個以上CONTINUATION フレーム

[80] HTTP/1.1 以下とは違って、 1xx 応答メッセージ内に入れ子に含まれる定義になっています。
[89] サーバープッシュ約束要求では、 HEADERS フレームのかわりに PUSH_PROMISE フレームを使います。 PUSH_PROMISE フレームとそれに続く CONTINUATION フレームは、親ストリームで送信されます。

[83] HEADERS フレームCONTINUATION フレームの間や CONTINUATION フレーム間に、 他のフレームがあってはなりません >>66

[81] 最後の HEADERSDATAフレームは、 END_STREAM フラグが設定されます >>66

[82] CONTINUATION フレームEND_STREAM フレームが存在せず、その直前の HEADERS フレームにかわりに設定されます。

[88] DATA フレームが存在しない場合、 ヘッダーリストが2つ連続することになります。

[99] 1xx ヘッダーの後 DATA を受信したらどうするべきかは定かではありません。

[100] Chrome200 として扱うようです。 (逆に仕様通り 1xx ヘッダーの後に次の HEADERS が現れるとストリームエラー PROTOCOL_ERROR とします。) FirefoxDATA フレームを受信したら接続を閉じます。

[90] payload body を持たない種別のメッセージDATA フレームが存在する場合や、 payload body を持つ種別のメッセージDATA フレームが存在しない場合にどうなるのかは謎です。

Content-Length の項も参照。

[101] ChromeFirefox も、長さ0の DATA はエラーとはしません。 Chrome は長さが非0でもエラーにせず、 XHR からアクセスできます。 Firefox は長さが非0だとストリームエラー CANCEL とします。

[103] Chrometrailer に対応していないようで、 ストリームエラー PROTOCOL_ERROR とします。

[84] trailerheader blockEND_STREAM が設定されてストリームが閉じられなかったとしても、 その後の header block は本メッセージの一部ではありません >>66

[85] 最終的な状態符号を受信した後に END_STREAM が設定されていない HEADERS フレームを受信したら、 そのメッセージは奇形として扱わなければなりません >>66

[102] Firefox はその場合接続エラー PROTOCOL_ERROR とするようです。

[104] ChromeFirefox も、 END_STREAM より前に GOAWAY を受信しても、エラーとはしないで接続を閉じる (FirefoxNO_ERRORGOAWAY を送信して閉じる) ようです。要求に対する応答ネットワークエラーとします。

[98] クライアント要求を送信していないストリームサーバーから HEADERS を受信した時どうしたらいいのかは定かではありません。

[96] 要求を送信していないストリームHEADERS を受信した時、 ChromeFirefox接続エラー PROTOCOL_ERROR とし、送信中の要求についてはネットワークエラーとするようです。

[86] ストリームの状態遷移の項も参照。

[87] 奇形の項も参照。

文脈

[2053] メッセージには要求メッセージ応答メッセージがあり、 それぞれ定義されている文脈で用いられます。 (それぞれの項とHTTP接続の項を参照してください。)

[2054] メッセージの一部又は全部のデータが送信されるタイミングについては、 HTTP接続の項を参照してください。

適合性

[16] 送信者は、 ABNF 生成規則により定義される文法一致しないプロトコル要素生成してはなりません >>13

[50] ABNF 生成規則の中には obs- から始まるものがありますが、 RFC 5322 とは違って obs- から始まるとしてもただちに不適合になるわけではないようです。 個別に不適合と規定されているものもあれば、何も言及がないものもあります。

[17] 送信者は、送信者の役割に応じて、その役割送信者が用いることを認められていないプロトコル要素や構文上の選択肢を用いてはなりません >>13

[15] 送信者は、であるとわかっていることを表しているプロトコル要素生成してはなりません >>13

[18] 受信者は、その役割に適用され、 ABNF 生成規則により定義される文法一致するような値を構文解析することができなければなりません >>13

[19] すべての受信者がすべてのプロトコル要素構文解析を義務付けられているわけではありません。 などメッセージ転送する中間器は、ヘッダー一般の構文解析を行って名前と値の組として認識はするでしょうが、 個々の値まで更に構文解析はしないで転送してしまいます。

[23] 受信者は、受信したプロトコル要素を適当な仕様書に従い解釈しなければなりません>>13

[24] ただし受信者が (経験や設定により) 送信者が誤って実装していると判定できるときは、 この限りではありません。 >>13

[25] 例えば、ある実装が特定の内容符号化の実装を誤っているとわかっており、 User-Agent: から受信者がその実装であると推測できるときは、 Accept-Encoding: を無視することができます。 >>13

[26] HTTPのエラー処理も参照してください。

長さの制限

[20] ほとんどのプロトコル要素には特定の長さの制限は設けられていません。 これは、利用される文脈や実装の目的により適切な長さが様々であるためとされています。 >>13

[21] 受信者は少なくても自身が同じプロトコル要素で生成し得る値と同じ長さは構文解析して処理できなければなりません >>13

[22] 例えばとても長い URL を出版する起源鯖は、それを要求URL として受け取って処理できる必要があります >>13

MIME 型

[519] テキスト形式のHTTPメッセージに完全に対応するMIME型はありませんが、 近い型は2つあります。

[520] application/http は、要求メッセージの列、 または応答メッセージの列を表します。

詳しくは application/http を参照してください。

[521] message/http は、 HTTPメッセージ1つを表すMIME型ですが、 MIMEmessage/* の制限が課される他、 いくつかの要件が本来のHTTPメッセージと異なっています。

[91] HTTP/2 を扱えるのかは不明です。

文脈

[528] message/httpTRACE 要求への応答として使われます >>2052

[54] S-HTTP でも message/http を使うと規定されていました >>60 が、 S-HTTP 自体が普及しませんでした。

引数

[529] message/http には省略可能な引数が2つ定義されています >>517

CTE

[526] message/httpCTE としては、 7bit, 8bit, binary だけが認められます >>517

[527] RFC 5335 によりこの制限は message/* 一般には撤廃されていますが、 RFC 7230 でも message/http に対しては引き続き課されているようです。

処理モデル

[51] message/http をどのように処理するべきかは規定されていません。 唯一使われる場面が TRACE 要求に対する応答ですが、 このメソッドデバッグ用だからか特に処理は規定されていません。

本体

[52] 本体は、 HTTPメッセージです。

[524] message/httpHTTPメッセージは、 行長に関する MIME の制限に従う必要があります >>517

[525] どの制限が不明です。 電子メールなどMIMEを使うプロトコルではなく、 MIMEの側に message/*本体部分行長宣言ってあるのでしょうか?

[530] message/httpHTTPメッセージに関しては、 折り畳みの禁止に関する制約が緩和されます。詳しくは行折り畳みを参照してください。

[531] なぜ敢えて例外規定を設けてまで、どれだけ実態があるかわからない message/http による利用を定義しているのか謎です。。。 電子メールでの転送を想定しているのかもしれませんが、唯一の用法である TRACE電子メールではありません。

関連

[522] HTTPメッセージRFC 822 メッセージの類似性から、必然的に message/httpmessage/rfc822 はよく似ています。

[523] 一般に HTTP メッセージCTEbinary です。7bit8bit の旧来の SMTPNNTP の如き転送路では転送することができません。他のMIME型であれば Base64Quoted-Printable のような CTE符号化するべきところですが、 MIME の規定により、 message/*符号化は一切禁止されているので、仕様に従いつつ転送する術はありません。 message/http の代わりに application/http として札付けすることでこの制約を回避できます。

API

[110] HTTPメッセージ API

歴史

[14] HTTP (RFC 1945 1.2, RFC 2068 1.3, RFC 2616 1.3)
message
The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in {1945] Section section 4 and transmitted via the connection.
メッセージ
HTTP 通信の基本単位で、第4章で定義する構文に一致する構造化オクテット列から成り、 接続を介して転送される。
[10] RFC 1945 4.1 Message Types

HTTP messages consist of requests from client to server and responses from server to client.

HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答 から構成されます。

       HTTP-message   = Simple-Request           ; HTTP/0.9 messages
                      | Simple-Response
                      | Full-Request             ; HTTP/1.0 messages
                      | Full-Response
   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).

Full-Request と Full-Response は実体の転送に RFC 822 の一般メッセージ形式を使います。両メッセージは省略可能な頭欄 (「頭達」とも呼ばれる) と実体本文を含んでも構いません。 実体本文は頭達と空行 (つまり CRLF の前に何も無い行) で区切ります。

       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
       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

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) に制限されます。

       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.

Simple-Request 形式の使用は非推奨です。 この形式では返される実体の媒体型を識別できないからです。

[11] RFC 2616 4.1 Message Types

HTTP messages consist of requests from client to server and responses from server to client.

HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への 応答で構成されます。

       HTTP-message   = Request | Response     ; HTTP/1.1 messages
   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.

Request, Response 両メッセージは実体 (メッセージの弾頭) の転送に RFC 822 の一般メッセージ形式を使います。両メッセージ型は star-line, 0個以上の頭欄 (「頭達」とも呼ばれる), 頭欄の終わりを示す空行 (つまり CRLF の前に何も無い行), それとあれば message-body から構成されます。

        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      = Request-Line | Status-Line
   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.

頑強性の点から、サーバーは Request-Line が来るはずのところで 受け取った空行を無視するべきです。他の言葉でいえば、サーバーが メッセージの始めのプロトコル列を読んで最初に CRLF を受け取ったなら、 その CRLF は無視するべきです。

   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.

イかれた HTTP/1.0 の顧客実装は余計な CRLF 達を POST 要求の後に生成します。 BNF で明示的に禁止されていることを 繰り返しますが、 HTTP/1.1 顧客は要求の前や後に余計な CRLF をつけてはいけません

[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

In addition to defining the {1945} HTTP/1.0 HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" {2616} and "application/http". {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 {1945} [13] {2616} [17] .

この文書は、 HTTP プロトコルを定義するのに加えて、インターネット媒体型 message/http および application/http の仕様を給仕します。message/http 型は、単一の HTTP 要求メッセージまたは応答メッセージを、すべての message 型についての行長と符号化に関する MIME の制限に従うものとして囲むために使うことができます。 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., {1945} "1.0" "1.1"). If not present, the version can be determined from the first line of the body.

囲まれたメッセージの HTTP-Version 番号 (例えば 1.01.1。) 存在しなければ、版は本体の最初の行から決定できます。

msgtype
The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.

メッセージ型 — request 又は response。 存在しなければ、型は本体の最初の行から決定できます。

Encoding considerations
only "7bit", "8bit", or "binary" are permitted
Security considerations
none

{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.

囲まれたメッセージの HTTP-Version 番号 (例えば 1.1。) 存在しなければ、版は本体の最初の行から決定できます。

msgtype
The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.

メッセージ型 — request 又は 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 メッセージは binary 書式です。 電子メイルを介して転送するときには適切な Content-Transfer-Encoding が必要です。

Security considerations
none
[2048] RFC 1945 (HTTP/1.0) 4.; RFC 2068・2616 (HTTP/1.1) 4 HTTP Message

4.1 Message Types

HTTP messages consist of requests from client to server and responses from server to client.

HTTP メッセージは、クライアントからサーバーへの要求サーバーからクライアントへの応答から成ります。

  •        HTTP-message   = Simple-Request           ; HTTP/0.9 messages
                          | Simple-Response
                          | Full-Request             ; HTTP/1.0 messages
                          | Full-Response
  • HTTP-message = Request | Response ; HTTP/1.1 messages

Full-Request Request (section 5) and Full-Response Response (section 6) messages use the generic message format of RFC 822 [7] [9] for transferring entities (the payload of the message). 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). Both types of message consist of a start-line, one 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 an optional possibly a message-body.

(完全)要求メッセージと(完全)応答メッセージは、実体 (メッセージの積荷) を転送するために RFC822 の一般メッセージ書式を使います。 メッセージのどちらの型も、 start-line (開始行)、一つ零個以上の頭欄 (とも)、頭欄並びの終わりを示す空行 (つまり CRLF の前に何も無い行)、 それにもしかすると message-body (メッセージ本体) から成ります。

  •        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
  •        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
  •            generic-message = start-line
                                 *message-header
                                 *(message-header CRLF)
                                 CRLF
                                 [ message-body ]
  • start-line = Request-Line | Status-Line

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 は頭情報の使用を認めず、要求方式も1つ (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.

Simple-Request 書式は、サーバーから返される実体の媒体型を識別することができませんから、 その使用は非推奨とします。

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.

頑強性の観点から、サーバーは Request-Line が期待されるところで受取った空行(並び)を無視するべきです。 言い換えると、サーバーがメッセージのはじめでプロトコル流を読んでいて最初に CRLF を受取ったら、この CRLF は無視するべきです。

Note: certain Certain buggy HTTP/1.0 client implementations generate an extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client must not MUST NOT preface or follow a request with an extra CRLF.

ある蝕まれた HTTP/1.0 クライアント実装は POST 要求の後に余分な CRLF を生成します。 BNF で陽に禁止されていることを繰り返しますが、 HTTP/1.1 クライアントは要求の前や後に余分な CRLF を入れてはいけません

注: 追加・削除は 1945→2068 のもの。追加中の追加・削除は 2068→2616 のもの。

4.2 Message Headers

HTTP//頭欄

RFC 2068・2616 4.3 Message Body

message-body

RFC 2068・2616 4.4 Message Length

Content-Length

RFC 1945 4.3; RFC 2068・2616 4.5 General Header Fields

一般頭欄

[2049] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 2.2 Basic Rules

The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by {1945} [17] {2068,2616} ANSI X3.4-1986 [21] .

次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。

  • OCTET = <any 8-bit sequence of data>
  • CHAR = <any US-ASCII character (octets 0 - 127)>
  • UPALPHA = <any US-ASCII uppercase letter "A".."Z">
  • LOALPHA = <any US-ASCII lowercase letter "a".."z">
  • ALPHA = UPALPHA | LOALPHA
  • DIGIT = <any US-ASCII digit "0".."9">
  • CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
  • CR = <US-ASCII CR, carriage return (13)>
  • LF = <US-ASCII LF, linefeed (10)>
  • SP = <US-ASCII SP, space (32)>
  • HT = <US-ASCII HT, horizontal-tab (9)>
  • <"> = <US-ASCII double-quote mark (34)>

HTTP/1.0 HTTP/1.1 defines the {1945} octet sequence CR LF as the end-of-line marker for all protocol elements except the {1945} Entity-Body entity-body (see {1945} Appendix B appendix 19.3 for tolerant applications). The end-of-line marker within an {1945} Entity-Body entity-body is defined by its associated media type, as described in {1945} Section 3.6 section 3.7.

HTTP は実体本体を除くすべてのプロトコル要素で列 CR LF を行末の (しるし) と定義します。 実体本体中の行末の印はその関連付けられた媒体型により定義されます。

  • CRLF = CR LF

HTTP/1.0 HTTP/1.1 {1945,2068} headers {2616} header field values {1945} may can be folded onto multiple lines if {1945} each the continuation line begins with a space or horizontal tab. All linear {1945} whitespace white space, including folding, has the same semantics as SP. {2616} A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.

HTTP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。 すべての線形空白は、折畳みも含み、 SP と同じ意味を持ちます。受信者は、欄値を解釈したり下流にメッセージを転送する前に任意の線形空白を単一の SP に置換しても構いません

  • LWS = [CRLF] 1*( SP | HT )

{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 応用は生成するべきではありません。

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 {1945,2068} may {2616} MAY contain {1945} octets characters from character sets other than {1945} US-ASCII {2068,2616} ISO 8859-1 ISO-8859-1 [22] only when encoded according to the rules of RFC 1522 2047 [14] .

TEXT 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。 *TEXT の語は US-ASCII RFC 2047 の規則に従って符号化するときのみ ISO-8859-1 以外の文字集合のオクテット文字を含んでも構いません

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

{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 文字集合の外のオクテットを含んだ頭欄 TEXT の受信者は、 それが ISO-8859-1 文字を表現するものと仮定しても構いません。

{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.

CRLF は、 TEXT の定義の中では、 頭欄継続の一部としてのみ認められています。 折畳み LWSTEXT 値の解釈の前に単一の SP に置換されることを意図定しています。

Hexadecimal numeric characters are used in several protocol elements.

十六進数文字は幾つかのプロトコル要素で使います。

  • HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

Many HTTP/1.0 HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters {1945} must MUST be in a quoted string to be used within a parameter value {2616} (as defined in section 3.6).

多くの HTTP 頭欄値は、 LWS または特殊文字で分離される語で構成されます。 特殊文字は引数値中で使うためには引用文字列中にいれなければなりません

{1945}

  • word = token | quoted-string

{1945,2068}

  • token = 1*<any CHAR except CTLs or tspecials>
  • tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

{2616}

  • token = 1*<any CHAR except CTLs or separators>
  • separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

Comments {1945} may 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 頭欄中に含めることができます。 注釈は、欄値定義の一部に comment を含んでいる欄でのみ認められます。 他のすべての欄では、括弧は欄値の一部とみなされます。

  • {1945,2068} comment = "(" *( ctext | comment ) ")"
  • {2616} comment = "(" *( ctext | quoted-pair | comment ) ")"
  • ctext = <any TEXT excluding "(" and ")">

A string of text is parsed as a single word if it is quoted using double-quote marks.

二重引用符を使って引用されている文字列は単一の語として解析します。

  • {1945,2068} quoted-string = ( <"> *(qdtext) <"> )
  • {2616} quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
  • {1945} qdtext = <any CHAR except <"> and CTLs, but including LWS>
  • {2068,2616} qdtext = <any TEXT except <">>

{1945} Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0.

HTTP/1.0 では逆斜線 (\) 文字を使った単一文字引用は認められていません。

{2068,2616} The backslash character ("\") may MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.

逆斜線文字 (\) は、 quoted-string 構造体および comment 構造体の中でのみ、 単一文字引用機構として使って構いません

  • quoted-pair = "\" CHAR
[2050] RFC 2326 (RTSP/1.0) 15 Syntax

The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used in RFC 2068 [2].

15.1 Base Syntax

   OCTET              =      <any 8-bit sequence of data>
   CHAR               =      <any US-ASCII character (octets 0 - 127)>
   UPALPHA            =      <any US-ASCII uppercase letter "A".."Z">
   LOALPHA            =      <any US-ASCII lowercase letter "a".."z">
   ALPHA              =      UPALPHA | LOALPHA
>
   DIGIT              =      <any US-ASCII digit "0".."9">
   CTL                =      <any US-ASCII control character
                              (octets 0 - 31) and DEL (127)>
   CR                 =      <US-ASCII CR, carriage return (13)>
   LF                 =      <US-ASCII LF, linefeed (10)>
>
   SP                 =      <US-ASCII SP, space (32)>
   HT                 =      <US-ASCII HT, horizontal-tab (9)>
   <">                =      <US-ASCII double-quote mark (34)>
   CRLF               =      CR LF
   LWS                =      [CRLF] 1*( SP | HT )
   TEXT               =      <any OCTET except CTLs>
   tspecials          =      "(" | ")" | "<" | ">" | "@"
                      |       "," | ";" | ":" | "\" | <">
                      |       "/" | "[" | "]" | "?" | "="
                      |       "{" | "}" | SP | HT
>
   token              =      1*<any CHAR except CTLs or tspecials>
   quoted-string      =      ( <"> *(qdtext) <"> )
   qdtext             =      <any TEXT except <">>
   quoted-pair        =      "\" CHAR
>
   message-header     =      field-name ":" [ field-value ] CRLF
   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, tspecials, and
                              quoted-string>
>
   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

訳注 : 編集上の誤りっぽいところがありますが、原文通りにしておきます。

[2051] RFC 2543 C.1; RFC 3261 25.1 (SIP/2.0) Basic Rules

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 で定義されています。

  • OCTET = <any 8-bit sequence of data>
  • CHAR = <any US-ASCII character (octets 0 - 127)>
  • 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 = <any US-ASCII control character
  • (octets 0 -- 31) and DEL (127)>
  • 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
  • alphanum = ALPHA / DIGIT

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 に適合するために更新したものです。

  • unreserved = alphanum | mark
  • mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
  • escaped = "%" hex hex
  • reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
  • unreserved = alphanum / mark
  • mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
  • escaped = "%" HEXDIG HEXDIG

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. 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 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。 すべての線形空白は、折畳みも含み、 SP と同じ意味を持ちます。受信者は、欄値を解釈したり下流にメッセージを転送する前に任意の線形空白を単一の SP に置換しても構いませんこれは RFC 2616 で説明されている HTTP/1.1 の場合と全く同じようになることを意図しています。 SWS 構造体は線形空白が省略可能である時、通常は字句と分離子の間で使います。

  • LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
  • LWS = [*WSP CRLF] 1*WSP ; linear whitespace
  • SWS = [LWS] ; sep whitespace

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.

頭名を残りの値と分離するためにコロンを使いますが、 これは上の規則により前に空白を求めるものの改行は認めず、 後には空白を改行も含めて認めます。 HCOLON はこの構造体を定義します。

  • HCOLON = *( SP / HTAB ) ":" SWS

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 character set (RFC 2279 [21]) charset (RFC 2279 [7]). 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.

TEXT-UTF8 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。 *TEXT-UTF8 の語は UTF-8 charset の文字だけを含めます。TEXT-UTF8-TRIM 規則は引用文字列ではなく、最初と最後の LWS が意味を持たない記述的欄内容に使用します。 この点では、 SIP は ISO 8859‐1 を使用する HTTP と異なります。

  • TEXT-UTF8 = <any UTF-8 character encoding, except CTLs, but including LWS>
  • 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

A CRLF is allowed in the definition of TEXT-UTF8-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-TRIM value.

CRLF は、 TEXT-TRIM の定義の中では、 頭欄継続の一部としてのみ認められています。 折畳み LWSTEXT-TRIM 値の解釈の前に単一の SP に置換されることを意図定しています。

Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case.

十六進数文字は幾つかのプロトコル要素で使います。幾つかの要素 (認証) は十六進字母が小文字であることを強制します。

  • hex = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | digit
  • LHEX = DIGIT / %x61-66 ;lowercase a-f

Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case-insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used.

多くの SIP 頭欄値は、 LWS または特殊文字で分離される語で構成されます。別途言及されていない限り、字句は大文字・小文字を区別します。 特殊文字は引数値中で使うためには引用文字列中にいれなければなりませんword 構造体は Call-ID でほとんどの分離子を使用できるようにするために使います。

  • token = 1*< any CHAR except CTL's or separators>
  • token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
  • separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
  • separators = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HTAB
  • word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" )

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

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 頭欄中に含めることができます。 注釈は、欄値定義の一部に comment を含んでいる欄でのみ認められます。 他のすべての欄では、括弧は欄値の一部とみなされます。

  • comment = "(" *(ctext | quoted-pair | comment) ")"
  • comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
  • ctext = < any TEXT-UTF8 excluding "(" and ")">
  • ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS

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. In quoted strings, quotation marks (") and backslashes (\) need to be escaped.

;ctext は左右の括弧と逆斜線を除くすべての文字を含みます。 二重引用符を使って引用されている文字列は単一の語として解析します。引用文字列中では、引用符 (") と逆斜線 (\) は escape する必要があります。

  • quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
  • quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
  • qdtext = <any TEXT-UTF8 except <">>
  • 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. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.

逆斜線文字 (\) は、 quoted-string 構造体および comment 構造体の中でのみ、 単一文字引用機構として使って構いませんHTTP/1.1 とは異なり、文字 CR 及び LF は行折畳みや頭分離との衝突を避けるためにこの機構を使って escape することはできません。

  • quoted-pair = " \ " CHAR
  • quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)

[12] Apache HTTP Server Project ( ( 版)) http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#force-response-1.0

[532] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.4.2

[2055] RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES) ( ( 版)) https://tools.ietf.org/html/rfc4236

[63] Final: OpenID Connect Core 1.0 incorporating errata set 1 ( 版) http://openid.net/specs/openid-connect-core-1_0.html#Terminology

Message

Request or a response between an OpenID Relying Party and an OpenID Provider.

[64] mod_proxy_http - Apache HTTP Server Version 2.4 ( 版) http://httpd.apache.org/docs/current/en/mod/mod_proxy_http.html

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.

[97] RFC 5989 - A SIP Event Package for Subscribing to Changes to an HTTP Resource ( 版) https://tools.ietf.org/html/rfc5989

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].