#?SuikaWiki/0.9
*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 形式の使用は非推奨です。
この形式では返される実体の媒体型を識別できないからです。
*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 をつけては'''いけません'''。
*RFC の部分の License
[[RFCのライセンス]]
*改行について
- [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]] と規定しているのですが...
[[#comment]]
*メモ