[2] 要求行request lineは、 要求メッセージの最初の行 (開始行) であり、要求メソッドと要求対象とプロトコルの版を表すものです。

仕様書

構文

[4] 要求行は、メソッド、 SP、要求対象、SP、 HTTPの版、CRLF を順に連ねたものです。 >>3

[504] ただし HTTP/0.9 では、メソッド、SP、要求対象、CRLF です >>10。 (HTTPの版がありません。)

  1. メソッド
  2. SP
  3. 要求対象
  4. ?
    1. SP
    2. HTTPの版
  5. CRLF

[6] 要求対象は、要求を適用する対象資源を識別します >>3。

[5] メソッドは、対象資源に対する要求メソッドを示します >>3。

[11] HTTP/0.9 ではメソッドは GET のみとなっています >>10。 それ以外の版では、任意の要求メソッドを指定できます。

[7] HTTPの版は、送信者が対応している最大のプロトコルの版を表します。 送信者はこの版に従い要求メッセージを生成することとなります。

[402] 要求行の長さに上限はありません >>3。しかし後述の通り、 受信者が任意の長さの要求行を処理する義務はありません。 送信者はむやみに長い要求行を送っていいわけではありません。

[12] 通常はハイパーリンクその他で鯖から与えられた URL を要求対象とするのでしょうから、受信者が処理できないほど長い URL が与えられるとは考えにくいですが、 URL を指定した鯖と受信者が別の者である場合や、 フォームなどで利用者の入力が長い場合などで長過ぎることはあり得ます。 一般にそのような場合に送信者が行える対策はありません。 (長い入力を想定している鯖は POST の payload body による引数の指定など代替策を用意しているでしょうが、 HTTP 仕様その他で一般的に機械的に適用できる対策はありません。)

構文解析

[8] 受信者は普通要求行を空白によって各部分に分割することで構文解析します >>3。仕様に適合するメッセージにおいては、メソッド、 要求対象、HTTPの版のいずれにも空白は含まれません。 しかし実際には空白を送信してくる利用者エージェントもあります >>3。 メソッドやHTTPの版には決して空白が含まれませんから、 前後を除去して残った部分を要求対象とすれば、曖昧無く解釈はできます。

[9] 非妥当な要求行を受け取った場合には、 400 を返すか、 301 で適切に符号化した要求対象にリダイレクトするかのいずれかにより応答するべきです。 リダイレクトなしで自動修正して処理するべきではありません。 >>3

[401] この規定は必ずしも守られていないように見えます。

[506] 構文上 SP の箇所は、空白1つ以上を区切りとみなして構文解析して構いません。 また、最初と CRLF 前の空白は無視して構いません。ここで空白は、 SP、HTAB、VT、FF、CR のことをいいます。 >>505

[17] Apache は 0x09 や 0x0C も空白として扱います。 nginx は 0x20 だけ空白とします。

[507] 改行については、メッセージの項を参照してください。

[503] 実際上要求行の長さには色々な制限が課されていますが、 最低でも8000オクテットの要求行には対応するべきです >>3。

[403] 実装しているどのメソッドよりも長いメソッド名を受信した鯖は、 501 を返すべきです >>3。

[502] 構文解析したい URI の長さを超える要求対象を受信した鯖は、 414 を返さなければなりません >>3。

[16] nginx も Apache も、先頭の 8192 バイトに要求行 (末尾の改行まで) が含まれないと、 414 応答を返します。 Apache は HTTP/1.1、nginx は HTTP/0.9 で返します。

[18] ChromeDriver はプロトコルの版が HTTP/1.1 でなければ、 直ちに接続HTTP接続を閉じます。 HTTP/1.0 や HTTP/1.2 であってはなりません。 (古い版の ChromeDriver はプロトコルの版を検査しておらず、何を指定しても HTTP/1.1 とみなしていたようです。)

歴史

[1] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 5.1 Request-Line

The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are {2616} is allowed except in the final CRLF sequence.

Request-Line は方式字句で始まり、 Request-URI とプロトコル版が続き、 CRLF で終わります。要素は SP 文字で分離します。最終 CRLF 列以外で CR と LF は認めていません。

  • Request-Line = Method SP Request-URI SP HTTP-Version CRLF

{1945} Note that the difference between a Simple-Request and the Request-Line of a Full-Request is the presence of the HTTP-Version field and the availability of methods other than GET.

Simple-Request と Full-Request の Request-Line との違いは HTTP-Version 欄があることと GET 以外の方式が利用可能であることであるのに注意してください。

5.1.1 Method

→HTTP//method

5.1.2 Request-URI

→Request-URI

[508] draft-aranda-dispatch-q4s-02 - The Quality for Service Protocol ( ( 版)) http://tools.ietf.org/html/draft-aranda-dispatch-q4s-02#page-17

関連

[13] HTTP/2 では、疑似ヘッダーが要求行の役割を果たしています。