25.txt

[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]] 版) <https://tools.ietf.org/html/rfc7230#section-3>
-- [49] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.4>
-- [514] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.5>
- [13] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-2.5>
- [517] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.3.1>
]REFS]

* 構文

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

* 構文解析

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

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

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

[37] 通常は [[HTTPメッセージ]]を次のように[[構文解析]]します [SRC[>>30]]。
= [38] [[開始行]]を読んで構造を解釈します。
= [39] [[空行]]に達するまで各[[ヘッダー]]を読んで、
[[ヘッダー名]]の[[ハッシュ表]]に入れます。
= [40] [[メッセージ本体]]があれば、[[メッセージ本体長]]分に達するか[[接続]]が閉じられるまでの[[オクテット]]を[[ストリーム]]として読みます。

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

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

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

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

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

* 不完全なメッセージ

[53] [[メッセージ]]は、[DFN[[RUBYB[[[不完全]]]@en[incomplete]]]]なことがあります。

[50] [[不完全]]な[[要求]] (中止された場合や[[タイムアウト]]の場合など。)
を受け取った[[鯖]]は、[[接続]]を閉じる前に[[誤り応答]]を送信して構いません [SRC[>>49]]。

[51] [[不完全]]な[[応答]] ([[接続]]が途中で閉じられた場合や [CODE(HTTP)[[[chunked]]]]
の[[復号]]が失敗した場合。) を受け取った[[クライアント]]は、
当該[[メッセージ]]を不完全と記録しなければ[['''なりません''']] [SRC[>>49]]。

;; [52] [[不完全]]な[[応答]]は[[キャッシュ]]の扱いが通常と異なります。

[54] [CODE(HTTP)@en[[[chunked]]]] [[転送符号化]]が用いられている場合、
長さが[[零]]の[[塊]]を受信していなければ、[[不完全]]です [SRC[>>49]]。

[55] [CODE(HTTP)@en[[[Content-Length:]]]] [[ヘッダー]]によって[[メッセージ本体]]の長さが決まる場合、
その値より[[メッセージ本体]]が短ければ、[[不完全]]です [SRC[>>49]]。
[[接続]]は閉じなければ[['''なりません''']] [SRC[>>30 3.3.3.]]。

[56] [[接続]]を閉じることによって[[メッセージ本体]]が終わる場合、
[[頭部]]をすべて受信していれば[[不完全]]ではありません [SRC[>>49]]。

* 適合性

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

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

* 改行

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

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

- [1] [[HTTP]] メッセージの頭の改行は [[CRLF]] で'''なければなりません'''が、 [CODE[Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS)]] というサーバーは [CODE[LF]] で出力します。 Mozilla や WinIE を含めた多くの [[UA]] はこれでも扱えるようですが、問題が出ることもあるみたいです。
- [2] >>1 例えば: ''Libraries of Kanazawa City'' <http://www.lib.kanazawa.ishikawa.jp/>
- [3] >>1-2 互換モードを作って対応するとしたら、 [[HTTP]] [[RFC]]s によると応答の最初の行には単独の [[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]] の話なので、影響するのは要求の最初の行の末だけです。

* 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メッセージ]]と異なっています。

** 文脈

[528] 実際にこの[[MIME型]]が使われる場面が存在するのかは不明です。

** 引数

[529] 省略可能な[[引数]]が2つ定義されています [SRC[>>517]]。
- [CODE(MIME)@en[[[version]]]]
- [CODE(MIME)@en[[[msgtype]]]]

** CTE

[526] [[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]]]] に対しては引き続き課されているようです。

** 制限

[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]]]] による利用を定義しているのか謎です。。。

** 関連

[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]]]]
として[[札付け]]することでこの制約を回避できます。

* 歴史

[FIG[
[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[
[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[
[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]

[12] [CITE[Apache HTTP Server Project]]
( ([TIME[2011-05-28 00:58:55 +09:00]] 版))
<http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#force-response-1.0>