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>
- [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>
]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]] [[応答]]は、[[開始行]]と[[ヘッダー]]がなく、全体が[[メッセージ本体]]となります。

* 構文解析

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

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

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

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

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

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

* 適合性

[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]] 単体ではありません。

- [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]] の話なので、影響するのは要求の最初の行の末だけです。

* 歴史

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

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