msgtype の値 response (MIME)
response 要素 (WebDAV)no-transform
407 CONNECT 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
を送信し、 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.2The 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 response 要素の子として複数回現れてはなりません。
この要件は、応答を線形時間で処理する経費を維持するために必要です。
特に、これによって href により全ての応答をまとめて集団化するための検索を行うことが防げます。
しかし、 href 値による順序付けについての要件はありません。<!ELEMENT
response(, ((href href*,)|(status +)),propstat ?) >responsedescription
n00 とみなすとなると、 3nn はみんな