メインコンテンツまでスキップ

3. リクエスト行 (Request Line)

リクエスト行は、メソッドトークンで始まり、その後に単一のスペース (SP)、リクエストターゲット、別の単一のスペース (SP) が続き、プロトコルバージョンで終わります。

request-line   = method SP request-target SP HTTP-version

リクエスト行の文法規則では、各構成要素が単一の SP オクテットで区切られる必要がありますが、受信者は代わりに空白区切りの単語境界で解析し、CRLF 終端子を除いて、任意の形式の空白を SP セパレーターとして扱い、先行または後続の空白を無視してもかまいません (MAY)。そのような空白には、SP、HTAB、VT (%x0B)、FF (%x0C)、または裸の CR のうち 1 つ以上のオクテットが含まれます。ただし、寛容な解析は、メッセージの複数の受信者が存在し、それぞれが独自の堅牢性の解釈を持っている場合、リクエストスマグリングセキュリティ脆弱性を引き起こす可能性があります (第 11.2 節参照)。

HTTP は、[HTTP] の第 2.3 節で説明されているように、リクエスト行の長さに事前定義された制限を設けていません。実装するどのメソッドよりも長いメソッドを受信するサーバーは、501 (Not Implemented) ステータスコードで応答すべきです (SHOULD)。解析したい任意の URI よりも長いリクエストターゲットを受信するサーバーは、414 (URI Too Long) ステータスコードで応答しなければなりません (MUST) ([HTTP] の第 15.5.15 節参照)。

実際には、リクエスト行の長さにさまざまなアドホックな制限があります。すべての HTTP 送信者と受信者は、最低でも 8000 オクテットのリクエスト行の長さをサポートすることが推奨されます (RECOMMENDED)。

3.1. メソッド (Method)​

メソッドトークンは、ターゲットリソースに対して実行されるリクエストメソッドを示します。リクエストメソッドは大文字小文字を区別します。

method         = token

本仕様書で定義されているリクエストメソッドは、HTTP メソッドレジストリと新しいメソッドを定義する際の考慮事項に関する情報とともに、[HTTP] の第 9 節にあります。

3.2. リクエストターゲット (Request Target)​

リクエストターゲットは、リクエストを適用するターゲットリソースを識別します。クライアントは、目的のターゲット URI からリクエストターゲットを導出します。リクエストターゲットには、リクエストされるメソッドとリクエストがプロキシへのものかどうかの両方に応じて、4 つの異なる形式があります。

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

リクエストターゲットには空白は許可されていません。残念ながら、一部のユーザーエージェントは、ハイパーテキスト参照に含まれる空白を適切にエンコードまたは除外できず、その結果、それらの許可されていない文字が不正なリクエスト行のリクエストターゲットとして送信されます。

無効なリクエスト行の受信者は、400 (Bad Request) エラーまたは適切にエンコードされたリクエストターゲットを含む 301 (Moved Permanently) リダイレクトのいずれかで応答すべきです (SHOULD)。受信者は、リダイレクトなしで自動修正してからリクエストを処理しようとすべきではありません (SHOULD NOT)。無効なリクエスト行は、リクエストチェーンに沿ったセキュリティフィルターをバイパスするために意図的に作成される可能性があるためです。

クライアントは、すべての HTTP/1.1 リクエストメッセージで Host ヘッダーフィールド ([HTTP] の第 7.2 節) を送信しなければなりません (MUST)。ターゲット URI に権限コンポーネントが含まれている場合、クライアントは、userinfo サブコンポーネントとその "@" デリミターを除いた ([HTTP] の第 4.2 節) その権限コンポーネントと同一の Host のフィールド値を送信しなければなりません (MUST)。ターゲット URI の権限コンポーネントが欠落しているか未定義の場合、クライアントは空のフィールド値を持つ Host ヘッダーフィールドを送信しなければなりません (MUST)。

サーバーは、Host ヘッダーフィールドを欠く任意の HTTP/1.1 リクエストメッセージ、および複数の Host ヘッダーフィールド行または無効なフィールド値を持つ Host ヘッダーフィールドを含む任意のリクエストメッセージに対して、400 (Bad Request) ステータスコードで応答しなければなりません (MUST)。

3.2.1. origin-form​

リクエストターゲットの最も一般的な形式は "origin-form" です。

origin-form    = absolute-path [ "?" query ]

オリジンサーバーに直接リクエストを行う場合 (以下で詳述する CONNECT またはサーバー全体の OPTIONS リクエスト以外)、クライアントは、ターゲット URI の絶対パスとクエリコンポーネントのみをリクエストターゲットとして送信しなければなりません (MUST)。ターゲット URI のパスコンポーネントが空の場合、クライアントはリクエストターゲットの origin-form 内のパスとして "/" を送信しなければなりません (MUST)。Host ヘッダーフィールドも、[HTTP] の第 7.2 節で定義されているように送信されます。

3.2.2. absolute-form​

プロキシにリクエストを行う場合 (以下で詳述する CONNECT またはサーバー全体の OPTIONS リクエスト以外)、クライアントはリクエストターゲットとしてターゲット URI を "absolute-form" で送信しなければなりません (MUST)。

absolute-form  = absolute-URI

3.2.3. authority-form​

リクエストターゲットの "authority-form" は、CONNECT リクエストでのみ使用されます ([HTTP] の第 9.3.6 節)。これは、コロン (":") で区切られたトンネル宛先の uri-host とポート番号のみで構成されます。

authority-form = uri-host ":" port

3.2.4. asterisk-form​

リクエストターゲットの "asterisk-form" は、サーバー全体の OPTIONS リクエストでのみ使用されます ([HTTP] の第 9.3.7 節)。

asterisk-form  = "*"

3.3. ターゲット URI の再構築 (Reconstructing the Target URI)​

リクエストターゲットが absolute-form の場合、ターゲット URI はリクエストターゲットです。その場合、サーバーはさらなる評価のために URI をその汎用コンポーネントに解析します。

それ以外の場合、サーバーは、ターゲットリソースを識別するために ([HTTP] の第 7.1 節)、接続コンテキストとリクエストメッセージのさまざまな部分からターゲット URI を再構築します。

に最終更新