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

`msgtype` の値 `response` (MIME)

[306] MIME型 message/http, application/http の msgtype 引数の値 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] プロキシが介在する (可能性のある) 場合、応答がプロキシで改変されている可能性もクライアントは考慮しておく必要があります。

プロキシ、HTTPキャッシュ、no-transform なども参照。

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

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

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

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

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

407、CONNECT も参照。

歴史

[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 の影響を記述する単一の応答を保持する
説明: 特定の href は multistatus XML 要素の下の response 要素の子として複数回現れてはなりません。この要件は、応答を線形時間で処理する経費を維持するために必要です。特に、これによって href により全ての応答をまとめて集団化するための検索を行うことが防げます。しかし、 href 値による順序付けについての要件はありません。