応答メッセージ

応答 (HTTP)

[305] 要求メッセージに対してクライアントへと返すHTTPメッセージのことを、 応答メッセージ (response message) といいます。

仕様書

構文

[22] HTTPメッセージを参照。

[23] 応答では、開始行状態行です。

文脈

[21] サーバーは、原則として要求を受信したら、 それに応じて応答を送信します。

[24] HTTP/1.1 では0個以上1xx 応答1xx 以外の「最後の応答」の列を送ることができます。

HTTP接続を参照。

[26] それ以外の HTTP では、応答を1個送ることができます。

[25] HTTP/2 では応答の最初に0個以上の 1xx 応答を含めることができます >>8

[27] HTTP/2 ではサーバー要求と同じストリーム応答を送信します >>8

応答の特性

[1] 応答の意味は、応答開始行である状態行に示される、 状態符号と呼ばれる3桁の数字列によって変わります。 状態符号によって応答の種類を表すことが多々あります。

[5] 例えば状態符号404 である応答のことを、 「404 応答」といいます。

[3] 応答にはヘッダーがあり、応答受信者の行うべき処理やメッセージの解釈その他の情報が含まれていることがあります。

[6] 応答には次の性質・状態があります。

[45] 応答
HTTPS状態
状態符号
理由句
プロトコルの版
ヘッダーリスト
キャッシュ可能性
満期時刻
新鮮寿命
新鮮/腐敗
forced sandboxing flag set
CSPenforce されるとき設定される砂箱化フラグ集合です。 設定されなければ空です。
内部応答
非安全応答
混合内容
非認証済応答

処理

[20] HTTP/2 サーバーは、要求をすべて受信する前であっても (要求全体が必要なければ) 応答を完了させることができます。その場合、応答の後に RST_STREAM フレーム誤り符号 NO_ERROR を送ることによって、クライアント要求の送信を止めるよう求めて構いません。 クライアントは、この RST_STREAM を受信したことを理由に応答を捨ててはなりません>>28

msgtype の値 response (MIME)

[306] MIME型 message/http, application/httpmsgtype 引数の値 response >>2, >>307 は、 要求を表します。

response 要素 (WebDAV)

[13] DAV: 名前空間response 要素は、資源特性に対する要求メソッドの効果を説明する応答を表します >>12

[14] response 要素内容要素内容で、 href 要素status 要素または propstat 要素error 要素responsedescription 要素location 要素を含められます >>12。 順序は意味を持ちません >>7

[18] href 要素は、WebDAV 資源HTTP URL を表します >>12

[15] status 要素を使用する場合には、 href 要素は複数含められます >>12。同じ値の href 要素を複数含めてはなりません >>12。順序は任意です >>12

[16] propstat 要素を使用する場合は href 要素は1つだけ含められます。 propstat 要素は複数含められます。 >>12

[17] error 要素responsedescription 要素は、省略可能で、 当該資源についての追加情報を提供するものです >>12

[19] location 要素は、省略可能です >>12

[11] response 要素は、 multistatus 要素子要素として任意の個数使うことができます >>10

セキュリティー

[31] プロキシが介在する (可能性のある) 場合、応答プロキシで改変されている可能性もクライアントは考慮しておく必要があります。

[32] 普通はプロキシクライアントが信用して選択するものですから、 プロキシが悪意を持つ可能性はあまり考えたくないですが、 まったく無視できるものでもありません。

[33] 歴史的にプロキシクライアントの間の通信は、平文HTTP で行われることが多いです。組織内の有線ネットワークなどある程度の信頼がおける環境ではそれで良いかもしれませんが、 公衆無線LAN等で悪意あるアクセスポイント等が混入し得る場合や通信事業者が認証帯域制御その他の目的で通信を改竄する場合があることも知られています。

[35] captive portal の応答やリダイレクトなどは、 (そうであると判定できるなら) キャッシュするべきではありません。 当該 URLの起源に属するデータにアクセスできるべきでもありません。 (がそのような判定は容易ではないかもしれません。従って HTTPS でない HTTP は安全ではありません。)

[34] 407 応答511 応答プロキシネットワーク認証が必要なことが示されている場合、 その応答起源サーバー由来でないことは明らかです。 そのような応答に含まれるスクリプトが当該 URLの起源に属するデータにアクセスできるのは、不適切かもしれません。

[36] プロキシまでの通信路が HTTP であっても、 CONNECT により TLS起源サーバーまで接続するのであれば、安全と考えられます。 しかしプロキシCONNECT 要求に対して 200 以外の応答を返したら、 それは起源サーバー由来ではありませんから、当該 URLの起源に属するデータにアクセスできるようにしてはいけません。

407CONNECT も参照。

歴史

[4] RFC 1945 (HTTP/1.0) 6.; RFC 2068・2616 (HTTP/1.1) 6 Response

After receiving and interpreting a request message, a server responds {1945} in the form of {2068,2616} with an HTTP response message.

要求メッセージを受信して解釈した後、サーバーは HTTP 応答メッセージで応答します。

{1945}

  • Response = Simple-Response | Full-Response

  • Simple-Response = [ Entity-Body ]
  •        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

{2068}

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

{2616}

  •        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

{1945} A Simple-Response should only be sent in response to an HTTP/0.9 Simple-Request or if the server only supports the more limited HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and receives a response that does not begin with a Status-Line, it should assume that the response is a Simple-Response and parse it accordingly. Note that the Simple-Response consists only of the entity body and is terminated by the server closing the connection.

Simple-Response は HTTP/0.9 Simple-Request への応答またはサーバーがより限定された HTTP/0.9 プロトコルしか対応していない場合のみ送信するべきです。 クライアントが HTTP/1.0 Full-Request を送信し、 Status-Line で始まらない応答を受信したら、 その応答は Simple-Response と仮定し、それに従って解析するべきです。 Simple-Response実体本体のみを含み、 サーバーが接続を閉じることで終端とすることに注意。

6.1 Status-Line

Status-Line

6.1.1 Status Code and Reason Phrase

状態符号

6.2 Response Header Fields

応答頭欄

[301] RFC 2616 6 Response

After receiving and interpreting a request message, a server responds with an HTTP response message.

要求メッセージを得て解釈した後、サーバーは 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

The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.

Response メッセージの最初の行は 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 状態符号と理由句

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.

Status-Code 要素は、要求を理解・満足しようとした結果の 3桁整数の符号です。この符号は10章で完全に定義します。 Reason-Phrase は Status-Code の短い文の説明を書き入れるものです。 Status-Code は自動装置が利用し、 Reason-Phrase は人間利用者が利用することを想定しています。顧客は Reason-Phrase を検査したり表示したりする必要はありません。

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

Status-Code の最初の数字は応答の級を表します。下2桁は分類役を 受け持っていません。最初の数字には5つの値があります。

  • 1xx: Informational - Request received, continuing process
  • 2xx: Success - The action was successfully received, understood, and accepted
  • 3xx: Redirection - Further action must be taken in order to complete the request
  • 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
  • 5xx: Server Error - The server failed to fulfill an apparently valid request
1xx
参考 — 要求は受け取られ、処理続行中
2xx
成功 — 行動は成功して受け取られ、理解され、認められました
3xx
あっち向け<!-- 訳語きぼんぬ --> — 要求を完了するには更なる行動が必要
4xx
顧客誤り — 要求の構文が悪いか満ち足りていません
5xx
サーバー誤り — サーバーは明らかに妥当な応答を用意するのに失敗しました

The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.

HTTP/1.1 に定義されている数値状態符号の個々の値と対応する Reason-Phrase の例の集合を次に示します。ここに示した理由句は 推奨に過ぎません。プロトコルに影響すること無しに地方の同等のものに 置き換えて構いません

      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 status codes are extensible. HTTP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached. For example, if an
   unrecognized status code of 431 is received by the client, it can
   safely assume that there was something wrong with its request and
   treat the response as if it had received a 400 status code. In such
   cases, user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include 
 human-readable information which will explain the unusual status.

HTTP 状態符号は拡張可能です。 HTTP 応用は登録されている全ての状態符号を 理解する必要はありません。理解出来る方が明らかに望ましいですけどね。 しかし、応用は状態符号の級, つまり最初の数字は理解出来なければなりません。 そして認識出来ない応答はその級の x00 の応答符号と同等のものとして 扱わなければなりません。例外として、認識出来ない応答は キャッシュしてはなりません。例えば、認識出来ない状態符号 431 を顧客が受け取った場合、要求の何かがおかしいと仮定出来、 400 の状態符号を受け取ったものとしてその応答を処理出来ます。 このような場合、利用者代理者は利用者に応答で返された実態を 提示するべきです。その実体にはその普通でない状態を説明する 人間可読情報が入っているでしょう。

[9] RFC 2518 (WebDAV) 12.9.1 response XML Element
Name
response
Namespace
DAV:
Purpose
Holds a single response describing the effect of a method on resource and/or its properties.
Description
A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values.
目的
資源及び/又はその特性についての method の影響を記述する単一の応答を保持する
説明
特定の hrefmultistatus XML 要素の下の response 要素の子として複数回現れてはなりません。 この要件は、応答を線形時間で処理する経費を維持するために必要です。 特に、これによって href により全ての応答をまとめて集団化するための検索を行うことが防げます。 しかし、 href 値による順序付けについての要件はありません。

<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) >

関連

[304] 状態符号HTTPの版HTTPヘッダーも参照してください。

メモ

[302] 未知は n00 とみなすとなると、 3nn はみんな 300 Multiple Choices になっちゃいますけど、いいんですかね?

[303] >>302 いいんです。 300 参照。

[29] Make the Response constructor throw when status is a null body status… · whatwg/fetch@590e99c ( 版) https://github.com/whatwg/fetch/commit/590e99c4614d126b1778587fb7ccc51e37901dab

[30] Fixing #118: add Response.prototype.body · whatwg/fetch@c51656b ( 版) https://github.com/whatwg/fetch/commit/c51656bf3c35e4fd7f83c3574c041806417b0da6

[37] Use the URL from the response, if it has one · whatwg/fetch@ed37f5e ( 版) https://github.com/whatwg/fetch/commit/ed37f5e4cf0ec6615f93b8a575d7349b977ffc3a

[38] Response construction with ReadableStream · whatwg/fetch@4924f6d ( 版) https://github.com/whatwg/fetch/commit/4924f6d6a2b9cdbdadffc1885141542311bda986

[39] Editorial: remove structured cloning section (annevk著, ) https://github.com/whatwg/fetch/commit/3dc1612fce7ab38673854d0bf26a4e118e52f077

[40] Editorial: remove a no-op from the Response constructor (annevk著, ) https://github.com/whatwg/fetch/commit/90cd540dc2a25df48b85a361f49901ac0835957b

[41] Make extract throw for a disturbed/locked ReadableStream (annevk著, ) https://github.com/whatwg/fetch/commit/1bda54532c11b51963796ad77f783e5d8e136ea8

[42] It is possible to construct a Request with a used body · Issue #792 · whatwg/fetch () https://github.com/whatwg/fetch/issues/792

[43] Make extract throw for a disturbed/locked ReadableStream by annevk · Pull Request #801 · whatwg/fetch () https://github.com/whatwg/fetch/pull/801

[44] Align with IDL constructor changes (autokagami著, ) https://github.com/whatwg/fetch/commit/eff7659a2cb15aed801a9dbfc00c58e22efbbd42