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

6. Response (レスポンス)

リクエストメッセージを受信して解釈した後、サーバーはHTTPレスポンスメッセージで応答します。

Response      = Status-Line               ; Section 6.1
                *(( general-header        ; Section 4.5
                 | response-header        ; Section 6.2
                 | entity-header ) CRLF)  ; Section 7.1
                CRLF
                [ message-body ]          ; Section 7.2

6.1 Status-Line (ステータスライン)​

レスポンスメッセージの最初の行はStatus-Lineで、プロトコルバージョンの後に数値ステータスコードとそれに関連するテキストフレーズが続き、各要素はSP文字で区切られます。最終的なCRLFシーケンスを除いて、CRまたはLFは許可されません。

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase (ステータスコードと理由フレーズ)​

Status-Code要素は、リクエストを理解して満たす試みの結果を示す3桁の整数結果コードです。これらのコードは第10節で完全に定義されています。Reason-Phraseは、Status-Codeの簡単なテキスト説明を提供することを目的としています。Status-Codeは自動機による使用を目的としており、Reason-Phraseは人間のユーザーによる使用を目的としています。クライアントは、Reason-Phraseを検査または表示する必要はありません。

Status-Codeの最初の桁は、レスポンスのクラスを定義します。最後の2桁には分類の役割はありません。最初の桁には5つの値があります：

  • 1xx: Informational (情報) - リクエストは受信され、処理が継続されます

  • 2xx: Success (成功) - 操作が正常に受信、理解、受け入れられました

  • 3xx: Redirection (リダイレクト) - リクエストを完了するためにさらなるアクションが必要です

  • 4xx: Client Error (クライアントエラー) - リクエストに誤った構文が含まれているか、完了できません

  • 5xx: Server Error (サーバーエラー) - サーバーが明らかに有効なリクエストの完了に失敗しました

HTTP/1.1用に定義された数値ステータスコードの個々の値と、対応するReason-Phraseの例のセットを以下に示します。ここにリストされている理由フレーズは単なる推奨事項です。プロトコルに影響を与えることなく、ローカルの同等物に置き換えることができます (MAY)。

Status-Code    =
         "100"  ; Section 10.1.1: Continue
       | "101"  ; Section 10.1.2: Switching Protocols
       | "200"  ; Section 10.2.1: OK
       | "201"  ; Section 10.2.2: Created
       | "202"  ; Section 10.2.3: Accepted
       | "203"  ; Section 10.2.4: Non-Authoritative Information
       | "204"  ; Section 10.2.5: No Content
       | "205"  ; Section 10.2.6: Reset Content
       | "206"  ; Section 10.2.7: Partial Content
       | "300"  ; Section 10.3.1: Multiple Choices
       | "301"  ; Section 10.3.2: Moved Permanently
       | "302"  ; Section 10.3.3: Found
       | "303"  ; Section 10.3.4: See Other
       | "304"  ; Section 10.3.5: Not Modified
       | "305"  ; Section 10.3.6: Use Proxy
       | "307"  ; Section 10.3.8: Temporary Redirect
       | "400"  ; Section 10.4.1: Bad Request
       | "401"  ; Section 10.4.2: Unauthorized
       | "402"  ; Section 10.4.3: Payment Required
       | "403"  ; Section 10.4.4: Forbidden
       | "404"  ; Section 10.4.5: Not Found
       | "405"  ; Section 10.4.6: Method Not Allowed
       | "406"  ; Section 10.4.7: Not Acceptable
       | "407"  ; Section 10.4.8: Proxy Authentication Required
       | "408"  ; Section 10.4.9: Request Time-out
       | "409"  ; Section 10.4.10: Conflict
       | "410"  ; Section 10.4.11: Gone
       | "411"  ; Section 10.4.12: Length Required
       | "412"  ; Section 10.4.13: Precondition Failed
       | "413"  ; Section 10.4.14: Request Entity Too Large
       | "414"  ; Section 10.4.15: Request-URI Too Large
       | "415"  ; Section 10.4.16: Unsupported Media Type
       | "416"  ; Section 10.4.17: Requested range not satisfiable
       | "417"  ; Section 10.4.18: Expectation Failed
       | "500"  ; Section 10.5.1: Internal Server Error
       | "501"  ; Section 10.5.2: Not Implemented
       | "502"  ; Section 10.5.3: Bad Gateway
       | "503"  ; Section 10.5.4: Service Unavailable
       | "504"  ; Section 10.5.5: Gateway Time-out
       | "505"  ; Section 10.5.6: HTTP Version not supported
       | extension-code

extension-code = 3DIGIT
Reason-Phrase  = *<TEXT, excluding CR, LF>

HTTPステータスコードは拡張可能です。HTTPアプリケーションは、すべての登録されたステータスコードの意味を理解する必要はありませんが、そのような理解が明らかに望ましいです。ただし、アプリケーションは、任意のステータスコードのクラス（最初の桁で示される）を理解しなければならず (MUST)、認識されないレスポンスを、そのクラスのx00ステータスコードと同等のものとして扱わなければなりません。ただし、認識されないレスポンスをキャッシュしてはなりません (MUST NOT)。たとえば、クライアントが認識されないステータスコード431を受信した場合、リクエストに問題があることを安全に想定でき、400ステータスコードを受信したかのようにレスポンスを処理できます。この場合、ユーザーエージェントは、レスポンスに含まれるエンティティをユーザーに提示すべき (SHOULD) です。なぜなら、そのエンティティには、異常なステータスを説明する人間が読める情報が含まれている可能性があるためです。

6.2 Response Header Fields (レスポンスヘッダフィールド)​

レスポンスヘッダフィールドを使用すると、サーバーは、Status-Lineに配置できないレスポンスに関する追加情報を渡すことができます。これらのヘッダフィールドは、サーバーに関する情報と、Request-URIで識別されるリソースへのさらなるアクセスに関する情報を提供します。

response-header = Accept-Ranges           ; Section 14.5
                | Age                     ; Section 14.6
                | ETag                    ; Section 14.19
                | Location                ; Section 14.30
                | Proxy-Authenticate      ; Section 14.33
                | Retry-After             ; Section 14.37
                | Server                  ; Section 14.38
                | Vary                    ; Section 14.44
                | WWW-Authenticate        ; Section 14.47

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

に最終更新