[305] [[要求メッセージ]]に対して[[鯖]]が[[クライアント]]へと返す[[HTTPメッセージ]]のことを、 [DFN[[RUBYB[[[応答メッセージ]]]@en[response message]]]]といいます。 * 仕様書 [REFS[ - [2] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [307] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [10] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [12] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [7] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [8] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) - [28] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) ]REFS] * 構文 [22] [[HTTPメッセージ]]を参照。 [23] [[応答]]では、[[開始行]]は[[状態行]]です。 * 文脈 [21] [[サーバー]]は、原則として[[要求]]を受信したら、 それに応じて[[応答]]を送信します。 [24] [[HTTP/1.1]] では0個[[以上]]の [CODE(HTTP)[[[1xx]]]] [[応答]]と [CODE(HTTP)[[[1xx]]]] ''以外''の「最後の[[応答]]」の列を送ることができます。 ;; [[HTTP接続]]を参照。 [26] それ以外の [[HTTP]] では、[[応答]]を1個送ることができます。 [25] [[HTTP/2]] では[[応答]]の最初に0個以上の [CODE(HTTP)[[[1xx]]]] [[応答]]を含めることができます [SRC[>>8]]。 [27] [[HTTP/2]] では[[サーバー]]は[[要求]]と同じ[[ストリーム]]で[[応答]]を送信します [SRC[>>8]]。 * 応答の特性 [1] [[応答]]の意味は、[[応答]]の[[開始行]]である[[状態行]]に示される、 [[状態符号]]と呼ばれる3桁の数字列によって変わります。 [[状態符号]]によって[[応答]]の種類を表すことが多々あります。 [EG[ [5] 例えば[[状態符号]]が [CODE(HTTP)[[[404]]]] である[[応答]]のことを、 「[CODE(HTTP)[[[404]]]] [[応答]]」といいます。 ]EG] [3] [[応答]]には[[ヘッダー]]があり、[[応答]]の[[受信者]]の行うべき処理や[[メッセージ]]の解釈その他の情報が含まれていることがあります。 [6] [[応答]]には次の性質・状態があります。 [FIG(list members)[ [45] [[応答]] :[[HTTPS状態]]: :[[状態符号]]: :[[理由句]]: :[[プロトコルの版]]: :[[ヘッダーリスト]]: :[[キャッシュ可能性]]: :[[満期時刻]]: :[[齢]]: :[[新鮮寿命]]: :[[新鮮]]/[[腐敗]]: :[[forced sandboxing flag set]]:[[CSP]] が [[enforce]] されるとき設定される[[砂箱化フラグ集合]]です。 設定されなければ空です。 : [F[内部応答]] : : [F[非安全応答]] : : [F[混合内容][Mixed Content]] : : [F[非認証済応答]] : ]FIG] * 処理 [20] [[HTTP/2]] [[サーバー]]は、[[要求]]をすべて受信する前であっても ([[要求]]全体が必要なければ) [[応答]]を完了させることができます。その場合、[[応答]]の後に [CODE[[[RST_STREAM]]]] [[フレーム]]で[[誤り符号]] [CODE[[[NO_ERROR]]]] を送ることによって、[[クライアント]]に[[要求]]の送信を止めるよう求めて構いません。 [[クライアント]]は、この [CODE[[[RST_STREAM]]]] を受信したことを理由に[[応答]]を捨てては[['''なりません''']]。 [SRC[>>28]] * [CODE(MIME)@en[msgtype]] の値 [CODE(MIME)@en[response]] (MIME) [306] [[MIME型]] [CODE(MIME)@en[[[message/http]]]], [CODE(MIME)@en[[[application/http]]]] の [CODE(MIME)@en[[[msgtype]]]] [[引数]]の値 [DFN[[CODE(MIME)@en[[[response]]]]]] [SRC[>>2, >>307]] は、 [[要求]]を表します。 * [CODE(XMLe)@en[response]] 要素 (WebDAV) [13] [CODE(URI)@en[[[DAV:]]]] [[名前空間]]の [DFN[[CODE(XMLe)@en[[[response]]]]]] [[要素]]は、[[資源]]や[[特性]]に対する[[要求メソッド]]の効果を説明する[[応答]]を表します [SRC[>>12]]。 [14] [CODE(XMLe)@en[[[response]]]] [[要素]]の[[内容]]は[[要素内容]]で、 [CODE(XMLe)@en[[[href]]]] [[要素]]、 [CODE(XMLe)@en[[[status]]]] [[要素]]または [CODE(XMLe)@en[[[propstat]]]] [[要素]]、 [CODE(XMLe)@en[[[error]]]] [[要素]]、[CODE(XMLe)@en[[[responsedescription]]]] [[要素]]、 [CODE(XMLe)@en[[[location]]]] [[要素]]を含められます [SRC[>>12]]。 順序は意味を持ちません [SRC[>>7]]。 [18] [CODE(XMLe)@en[[[href]]]] [[要素]]は、[[WebDAV]] [[資源]]の [[HTTP URL]] を表します [SRC[>>12]]。 [15] [CODE(XMLe)@en[[[status]]]] [[要素]]を使用する場合には、 [CODE(XMLe)@en[[[href]]]] [[要素]]は複数含められます [SRC[>>12]]。同じ値の [CODE(XMLe)@en[[[href]]]] [[要素]]を複数含めては[['''なりません''']] [SRC[>>12]]。順序は任意です [SRC[>>12]]。 [16] [CODE(XMLe)@en[[[propstat]]]] [[要素]]を使用する場合は [CODE(XMLe)@en[[[href]]]] [[要素]]は1つだけ含められます。 [CODE(XMLe)@en[[[propstat]]]] [[要素]]は複数含められます。 [SRC[>>12]] [17] [CODE(XMLe)@en[[[error]]]] [[要素]]、 [CODE(XMLe)@en[[[responsedescription]]]] [[要素]]は、省略可能で、 当該[[資源]]についての追加情報を提供するものです [SRC[>>12]]。 [19] [CODE(XMLe)@en[[[location]]]] [[要素]]は、省略可能です [SRC[>>12]]。 [11] [CODE(XMLe)@en[[[response]]]] [[要素]]は、 [CODE(XMLe)@en[[[multistatus]]]] [[要素]]の[[子要素]]として任意の個数使うことができます [SRC[>>10]]。 * セキュリティー [31] [[プロキシ]]が介在する (可能性のある) 場合、[[応答]]が[[プロキシ]]で改変されている可能性も[[クライアント]]は考慮しておく必要があります。 ;; [[プロキシ]]、[[HTTPキャッシュ]]、[CODE[[[no-transform]]]] なども参照。 [32] 普通は[[プロキシ]]は[[クライアント]]が信用して選択するものですから、 [[プロキシ]]が悪意を持つ可能性はあまり考えたくないですが、 まったく無視できるものでもありません。 ;; [33] 歴史的に[[プロキシ]]と[[クライアント]]の間の通信は、[[平文]]の [[HTTP]] で行われることが多いです。組織内の有線ネットワークなどある程度の信頼がおける環境ではそれで良いかもしれませんが、 [[公衆無線LAN]]等で悪意ある[[アクセスポイント]]等が混入し得る場合や通信事業者が[[認証]]、[[帯域]]制御その他の目的で通信を改竄する場合があることも知られています。 [35] [[captive portal]] の応答やリダイレクトなどは、 (そうであると判定できるなら) [[キャッシュ]]するべきではありません。 当該 [[URLの起源]]に属するデータにアクセスできるべきでもありません。 (がそのような判定は容易ではないかもしれません。従って [[HTTPS]] でない [[HTTP]] は安全ではありません。) [34] [CODE(HTTP)[[[407]]]] [[応答]]や [CODE(HTTP)[[[511]]]] [[応答]]で[[プロキシ]]や[[ネットワーク]]の[[認証]]が必要なことが示されている場合、 その[[応答]]は[[起源サーバー]]由来でないことは明らかです。 そのような[[応答]]に含まれる[[スクリプト]]が当該 [[URLの起源]]に属するデータにアクセスできるのは、不適切かもしれません。 [36] [[プロキシ]]までの通信路が [[HTTP]] であっても、 [CODE(HTTP)@en[[[CONNECT]]]] により [[TLS]] で[[起源サーバー]]まで接続するのであれば、安全と考えられます。 しかし[[プロキシ]]が [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]に対して [CODE(HTTP)[[[200]]]] 以外の[[応答]]を返したら、 それは[[起源サーバー]]由来ではありませんから、当該 [[URLの起源]]に属するデータにアクセスできるようにしてはいけません。 ;; [CODE(HTTP)[[[407]]]]、[CODE(HTTP)@en[[[CONNECT]]]] も参照。 * 歴史 [FIG(quote)[ [FIGCAPTION[ [4] RFC 1945 (HTTP/1.0) 6.; RFC 2068・2616 (HTTP/1.1) 6 Response ]FIGCAPTION] > After receiving and interpreting a request message, a server responds [DEL[[INS[{1945}]] in the form of]] [INS[[INS[{2068,2616}]] with]] an HTTP response message. 要求メッセージを受信して解釈した後、サーバーは HTTP 応答メッセージで応答します。 [DEL[ [DEL[ > [INS[{1945}]] - Response = Simple-Response | Full-Response > - Simple-Response = [ Entity-Body ] > - [PRE[ 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 ]PRE] ]DEL] [INS[ > [INS[{2068}]] - [PRE[ 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 ]PRE] ]INS] ]DEL] [INS[ > [INS[{2616}]] - [PRE[ 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 ]PRE] ]INS] [DEL[ > [INS[{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. [CODE(ABNF)[Simple-Response]] は HTTP/0.9 [CODE(ABNF)[Simple-Request]] への応答またはサーバーがより限定された HTTP/0.9 プロトコルしか対応していない場合のみ送信するべきです。 クライアントが HTTP/1.0 [CODE(ABNF)[Full-Request]] を送信し、 [CODE(ABNF)[[[Status-Line]]]] で始まらない応答を受信したら、 その応答は [CODE(ABNF)[Simple-Response]] と仮定し、それに従って解析するべきです。 [CODE(ABNF)[Simple-Response]] は[[実体本体]]のみを含み、 サーバーが接続を閉じることで終端とすることに注意。 ]DEL] *** 6.1 Status-Line →[CODE(WikiPage)[[[Status-Line]]]] **** 6.1.1 Status Code and Reason Phrase →[CODE(WikiPage)[[[状態符号]]]] *** 6.2 Response Header Fields →[CODE(WikiPage)[[[応答頭欄]]]] ]FIG] [FIG[ [FIGCAPTION[ [301] RFC 2616 6 Response ]FIGCAPTION] 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 = * 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 の状態符号を受け取ったものとしてその応答を処理出来ます。 このような場合、利用者代理者は利用者に応答で返された実態を 提示する'''べきです'''。その実体にはその普通でない状態を説明する 人間可読情報が入っているでしょう。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [9] RFC 2518 (WebDAV) 12.9.1 response XML Element ]FIGCAPTION] > : Name: [CODE(DAVe)[response]] : Namespace: [CODE(URI)[[[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 の影響を記述する単一の応答を保持する :説明: 特定の [CODE(DAVe)[href]] は [CODE(DAVe)[[[multistatus]]]] XML 要素の下の [CODE(DAVe)[response]] 要素の子として複数回現れては'''なりません'''。 この要件は、応答を線形時間で処理する経費を維持するために必要です。 特に、これによって [CODE(DAVe)[href]] により全ての応答をまとめて集団化するための検索を行うことが防げます。 しかし、 [CODE(DAVe)[href]] 値による順序付けについての要件はありません。 > ]FIG] * 関連 [304] [[状態符号]]、[[HTTPの版]]、[[HTTPヘッダー]]も参照してください。 * メモ [302] 未知は [CODE(HTTP)[[VAR[n]]00]] とみなすとなると、 [CODE(HTTP)[3[VAR[nn]]]] はみんな [CODE(HTTP)[[[300]] Multiple Choices]] になっちゃいますけど、いいんですかね? [303] >>302 いいんです。 [CODE(WikiPage)[[[300]]]] 参照。 [29] [CITE@en[Make the Response constructor throw when status is a null body status… · whatwg/fetch@590e99c]] ([TIME[2015-07-24 22:57:42 +09:00]] 版) [30] [CITE@en[Fixing #118: add Response.prototype.body · whatwg/fetch@c51656b]] ([TIME[2015-10-07 13:43:43 +09:00]] 版) [37] [CITE@en[Use the URL from the response, if it has one · whatwg/fetch@ed37f5e]] ([TIME[2015-11-05 17:18:45 +09:00]] 版) [38] [CITE@en[Response construction with ReadableStream · whatwg/fetch@4924f6d]] ([TIME[2016-04-15 17:43:46 +09:00]] 版) [39] [CITE@en[Editorial: remove structured cloning section]] ([[annevk]]著, [TIME[2016-08-10 22:50:02 +09:00]]) [40] [CITE@en[Editorial: remove a no-op from the Response constructor]] ([[annevk]]著, [TIME[2017-02-08 20:27:09 +09:00]]) [41] [CITE@en[Make extract throw for a disturbed/locked ReadableStream]] ([[annevk]]著, [TIME[2018-08-28 14:59:24 +09:00]]) [42] [CITE@en[It is possible to construct a Request with a used body · Issue #792 · whatwg/fetch]] ([TIME[2018-09-17 18:19:07 +09:00]]) [43] [CITE@en[Make extract throw for a disturbed/locked ReadableStream by annevk · Pull Request #801 · whatwg/fetch]] ([TIME[2018-09-17 18:19:51 +09:00]]) [44] [CITE@en[Align with IDL constructor changes]] ([[autokagami]]著, [TIME[2019-09-24 22:59:53 +09:00]])