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

5. Request (リクエスト)

クライアントからサーバーへのリクエストメッセージは、そのメッセージの最初の行に、リソースに適用するメソッド (method)、リソースの識別子 (identifier)、および使用されているプロトコルバージョンを含みます。

Request       = Request-Line              ; Section 5.1
                *(( general-header        ; Section 4.5
                 | request-header         ; Section 5.3
                 | entity-header ) CRLF)  ; Section 7.1
                CRLF
                [ message-body ]          ; Section 4.3

5.1 Request-Line (リクエストライン)​

Request-Lineはメソッドトークン (method token) で始まり、その後にRequest-URIとプロトコルバージョンが続き、CRLFで終了します。要素はSP文字で区切られます。最終的なCRLFシーケンスを除いて、CRまたはLFは許可されません。

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

5.1.1 Method (メソッド)​

Methodトークンは、Request-URIで識別されるリソースに対して実行されるメソッドを示します。メソッドは大文字小文字を区別します。

Method         = "OPTIONS"                ; Section 9.2
               | "GET"                    ; Section 9.3
               | "HEAD"                   ; Section 9.4
               | "POST"                   ; Section 9.5
               | "PUT"                    ; Section 9.6
               | "DELETE"                 ; Section 9.7
               | "TRACE"                  ; Section 9.8
               | "CONNECT"                ; Section 9.9
               | extension-method
extension-method = token

リソースで許可されているメソッドのリストは、Allowヘッダフィールド（第14.7節）で指定できます。レスポンスの返却コードは、リソースに対して現在メソッドが許可されているかどうかを常にクライアントに通知します。これは、許可されたメソッドのセットが動的に変更される可能性があるためです。オリジンサーバーがメソッドを認識しているが、リクエストされたリソースに対してそのメソッドの使用を許可していない場合、オリジンサーバーはステータスコード405（Method Not Allowed）を返すべき (SHOULD) です。オリジンサーバーがメソッドを認識していない、またはメソッドが実装されていない場合は、501（Not Implemented）を返すべきです。すべての汎用サーバーは、GETおよびHEADメソッドをサポートしなければなりません (MUST)。その他のすべてのメソッドはオプション (OPTIONAL) です。ただし、上記のメソッドが実装されている場合、第9節で指定されているのと同じセマンティクスで実装しなければなりません (MUST)。

5.1.2 Request-URI (リクエストURI)​

Request-URIは、リクエストが適用されるリソースを識別する統一資源識別子 (Uniform Resource Identifier)（第3.2節）です。

Request-URI    = "*" | absoluteURI | abs_path | authority

Request-URIの4つのオプションは、リクエストの性質に依存します。アスタリスク "*" は、リクエストが特定のリソースに適用されるのではなく、サーバー自体に適用されることを意味し、使用されるメソッドが必ずしもリソースに適用されない場合にのみ許可されます。例：

OPTIONS * HTTP/1.1

absoluteURI形式は、リクエストがプロキシに送信される場合に使用されます。プロキシは、リクエストを転送するか、有効なキャッシュからサービスを提供し、レスポンスを返すよう要求されます。プロキシは、リクエストを次のインバウンドサーバーに転送する前に、リクエストを別のプロキシに転送するか、absoluteURIで指定されたサーバーに直接転送できます (MAY)。リクエストループを避けるため、プロキシは、エイリアス、ローカルバリエーション、数値IPアドレスを含むすべてのサーバー名を認識できなければなりません (MUST)。リクエストの例：

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

すべてのリクエストでabsoluteURIの使用への移行を可能にするため（将来のHTTPバージョン）、すべてのHTTP/1.1サーバーは、HTTP/1.1クライアントがプロキシにリクエストを行う場合にのみそれらを生成する場合でも、リクエスト内のabsoluteURI形式を受け入れなければなりません (MUST)。

authority形式は、CONNECTメソッド（第9.9節）によってのみ使用されます。

最も一般的なRequest-URI形式は、オリジンサーバーまたはゲートウェイ上のリソースを識別するために使用されます。この場合、URIの絶対パスはRequest-URIとして送信されなければならず (MUST)、ネットワークロケーションはHostヘッダフィールドで送信されなければなりません (MUST)。たとえば、クライアントがオリジンサーバーから直接リソースを取得したい場合、ホスト "www.w3.org" のポート80へのTCP接続を作成し、次の行を送信します：

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

その後、リクエストの残りの部分が続きます。ポート番号が指定されていない場合、HTTPのデフォルトポートである80が想定されることに注意してください。

プロキシがこのようなリクエストを受信した場合、すでに存在していない限り、リクエストを転送する前にHostヘッダフィールドをリクエストに追加しなければなりません (MUST)。（Hostの詳細については、第14.23節を参照してください。）

Request-URIがスラッシュで始まる場合、それはabs_pathとして扱われます。受信者は、空のabs_pathをabsoluteURIのabs_pathが "/" であるかのように解釈しなければなりません (MUST)。

すべてのHTTP/1.1クライアントは、HTTP/1.1リクエストメッセージを生成する際にHostヘッダフィールドを含めなければなりません (MUST)。HTTP/1.1リクエストにHostヘッダフィールドが欠けている場合、サーバーはそのリクエストに対して400（Bad Request）で応答しなければなりません (MUST)。

プロキシ要件の詳細については、第5.2節を参照してください。

5.2 The Resource Identified by a Request (リクエストによって識別されるリソース)​

HTTPオリジンサーバーは、通常、特定の名前空間 (namespace) 内にそのリソースを編成します。Request-URIは、その名前空間内のリソースを識別します。インターネット上では、HTTPオリジンサーバーは通常、インターネットホストを介してアクセス可能であり、（HTTPと一緒に使用される場合）"http" または "https" スキームを使用した絶対URIとして識別されます。オリジンサーバーは、1つ以上の名前空間をサポートでき (MAY)、（HTTPと一緒に使用される場合）1つ以上のスキームのURIを同時にサポートする可能性があります。

次のRequest-Lineを考えてみましょう：

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Request-URIは、リソースを次のように識別します：

http://www.w3.org/pub/WWW/TheProject.html

このリクエストがオリジンサーバー www.w3.org に直接到達する場合、サーバーは、そのサーバー上の "/pub/WWW/TheProject.html" パスに位置するリソースに対して操作を実行すべき (SHOULD) です。

このリクエストがプロキシに到達する場合、Request-URIはオリジンサーバーを指定し、プロキシはそのサーバーに連絡すべき (SHOULD) です（第13節で説明されているように、独自のキャッシュを使用する可能性があります）。クライアントがリクエストで提供するURIは、サーバーがリソースを識別するために内部的に使用するURIとは異なる場合があることに注意してください。

インターネット上のオリジンサーバーが使用する正確なリソース識別方法は、この仕様の範囲外です。この仕様は、HTTPの実装を制限して、ディレクトリベースのファイルシステムを使用してリクエストを満たすことを要求するものではありません。HTTPが与えられたリソースへのリクエストを識別するために使用するURIのみが使用されます。

5.3 Request Header Fields (リクエストヘッダフィールド)​

リクエストヘッダフィールドを使用すると、クライアントはリクエストに関する追加情報とクライアント自体に関する情報をサーバーに渡すことができます。これらのフィールドは、リクエスト修飾子として機能し、そのセマンティクスはプログラミング言語のメソッド呼び出しのパラメータと同等です。

request-header = Accept                   ; Section 14.1
               | Accept-Charset           ; Section 14.2
               | Accept-Encoding          ; Section 14.3
               | Accept-Language          ; Section 14.4
               | Authorization            ; Section 14.8
               | Expect                   ; Section 14.20
               | From                     ; Section 14.22
               | Host                     ; Section 14.23
               | If-Match                 ; Section 14.24
               | If-Modified-Since        ; Section 14.25
               | If-None-Match            ; Section 14.26
               | If-Range                 ; Section 14.27
               | If-Unmodified-Since      ; Section 14.28
               | Max-Forwards             ; Section 14.31
               | Proxy-Authorization      ; Section 14.34
               | Range                    ; Section 14.35
               | Referer                  ; Section 14.36
               | TE                       ; Section 14.39
               | User-Agent               ; Section 14.43

リクエストヘッダフィールド名は、プロトコルバージョンを変更することによってのみ確実に拡張できます。ただし、プロトコルバージョンを変更することなく、フィールド値に新しいまたは実験的なヘッダフィールドを付与できます。認識されないヘッダフィールドは、受信者によってエンティティヘッダフィールドとして扱われるべき (SHOULD) です。

に最終更新