[305] 要求メッセージに対して鯖がクライアントへと返すHTTPメッセージのことを、 応答メッセージといいます。
[21] サーバーは、原則として要求を受信したら、 それに応じて応答を送信します。
[24] HTTP/1.1 では0個以上の 1xx
応答と
1xx
以外の「最後の応答」の列を送ることができます。
[26] それ以外の HTTP では、応答を1個送ることができます。
[1] 応答の意味は、応答の開始行である状態行に示される、 状態符号と呼ばれる3桁の数字列によって変わります。 状態符号によって応答の種類を表すことが多々あります。
[3] 応答にはヘッダーがあり、応答の受信者の行うべき処理やメッセージの解釈その他の情報が含まれていることがあります。
[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] プロキシが介在する (可能性のある) 場合、応答がプロキシで改変されている可能性もクライアントは考慮しておく必要があります。
[32] 普通はプロキシはクライアントが信用して選択するものですから、 プロキシが悪意を持つ可能性はあまり考えたくないですが、 まったく無視できるものでもありません。
[35] captive portal の応答やリダイレクトなどは、 (そうであると判定できるなら) キャッシュするべきではありません。 当該 URLの起源に属するデータにアクセスできるべきでもありません。 (がそのような判定は容易ではないかもしれません。従って HTTPS でない HTTP は安全ではありません。)
[34] 407
応答や 511
応答でプロキシやネットワークの認証が必要なことが示されている場合、
その応答は起源サーバー由来でないことは明らかです。
そのような応答に含まれるスクリプトが当該 URLの起源に属するデータにアクセスできるのは、不適切かもしれません。
[36] プロキシまでの通信路が HTTP であっても、 CONNECT
により TLS で起源サーバーまで接続するのであれば、安全と考えられます。
しかしプロキシが CONNECT
要求に対して 200
以外の応答を返したら、
それは起源サーバー由来ではありませんから、当該 URLの起源に属するデータにアクセスできるようにしてはいけません。
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
は実体本体のみを含み、
サーバーが接続を閉じることで終端とすることに注意。
→状態符号
→応答頭欄
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
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
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つの値があります。
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 の状態符号を受け取ったものとしてその応答を処理出来ます。 このような場合、利用者代理者は利用者に応答で返された実態を 提示するべきです。その実体にはその普通でない状態を説明する 人間可読情報が入っているでしょう。
- 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.
href
は multistatus
XML 要素の下の
response
要素の子として複数回現れてはなりません。
この要件は、応答を線形時間で処理する経費を維持するために必要です。
特に、これによって href
により全ての応答をまとめて集団化するための検索を行うことが防げます。
しかし、 href
値による順序付けについての要件はありません。<!ELEMENT
response
(href
, ((href
*,status
)|(propstat
+)),responsedescription
?) >
[302] 未知は n00
とみなすとなると、 3nn
はみんな 300 Multiple Choices
になっちゃいますけど、いいんですかね?
[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