Changeset 1750
- Timestamp:
- 09/07/12 19:06:58 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1747 r1750 1186 1186 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF. 1187 1187 </p> 1188 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status -code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1188 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1189 1189 </pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message. 1190 1190 </p> 1191 <div id="status-code"> 1192 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1193 for new status codes. 1194 </p> 1195 </div> 1196 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status-code" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1197 </pre><div id="reason-phrase"> 1198 <p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1199 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1200 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. 1201 </p> 1202 </div> 1203 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#reason-phrase" class="smpl">reason-phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1191 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1192 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1193 for that status code. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit), 1194 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1195 </p> 1196 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status.line" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1197 </pre><p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1198 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1199 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. 1200 </p> 1201 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#status.line" class="smpl">reason-phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1204 1202 </pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> 1205 1203 <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field … … 1379 1377 </p> 1380 1378 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1381 status code (<a href="#status -code">Paragraph 4</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)1379 status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1382 1380 </p> 1383 1381 <div id="rfc.iref.t.4"></div> … … 1405 1403 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1406 1404 </p> 1407 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2. 10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1408 </p> 1409 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4. 2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer1405 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1406 </p> 1407 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer 1410 1408 coding to the message body if the request had been an unconditional GET. This indication is not required, however, because 1411 1409 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. … … 1427 1425 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Length: 3495 1428 1426 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1429 transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4. 3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would1427 transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would 1430 1428 have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1431 1429 </p> … … 1703 1701 </p> 1704 1702 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1705 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1703 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1706 1704 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1707 1705 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1745 1743 </p> 1746 1744 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1747 are defined in <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order1745 are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order 1748 1746 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1749 1747 identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). … … 1804 1802 </p> 1805 1803 <div id="authority-form"> 1806 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1804 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1807 1805 </p> 1808 1806 </div> 1809 1807 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1810 1808 </pre><div id="asterisk-form"> 1811 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1809 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1812 1810 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1813 1811 </p> … … 1956 1954 </p> 1957 1955 <ul> 1958 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1956 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1959 1957 </li> 1960 1958 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 1961 1959 </li> 1962 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1960 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1963 1961 </li> 1964 1962 </ul> … … 1970 1968 </p> 1971 1969 </div> 1972 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.1 7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1970 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1973 1971 </p> 1974 1972 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1975 1973 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1976 1974 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1977 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.1975 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request. 1978 1976 </p> 1979 1977 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. … … 2120 2118 <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2121 2119 </p> 2122 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2120 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2123 2121 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2124 2122 </p> … … 2150 2148 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2151 2149 <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2152 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2150 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2153 2151 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2154 2152 </p> … … 2163 2161 </p> 2164 2162 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2165 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.2 1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2163 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2166 2164 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2167 2165 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2170 2168 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2171 2169 <ul> 2172 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.2 2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.2170 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation. 2173 2171 </li> 2174 2172 <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body. … … 2208 2206 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 2209 2207 </li> 2210 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.2 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2208 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2211 2209 </li> 2212 2210 </ul> … … 2245 2243 </p> 2246 2244 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2247 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.2 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2245 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2248 2246 </p> 2249 2247 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching … … 2509 2507 <li>Pointer to specification text</li> 2510 2508 </ul> 2511 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.2 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2509 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2512 2510 </p> 2513 2511 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 2668 2666 that most implementations will choose substantially higher limits. 2669 2667 </p> 2670 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.2 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2668 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2671 2669 </p> 2672 2670 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 3095 3093 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3096 3094 3097 <a href="# reason-phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text )3095 <a href="#status.line" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text ) 3098 3096 <a href="#header.via" class="smpl">received-by</a> = ( uri-host [ ":" port ] ) / pseudonym 3099 3097 <a href="#header.via" class="smpl">received-protocol</a> = [ protocol-name "/" ] protocol-version … … 3106 3104 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3107 3105 <a href="#http.message" class="smpl">start-line</a> = request-line / status-line 3108 <a href="#status -code" class="smpl">status-code</a> = 3DIGIT3106 <a href="#status.line" class="smpl">status-code</a> = 3DIGIT 3109 3107 <a href="#status.line" class="smpl">status-line</a> = HTTP-version SP status-code SP reason-phrase CRLF 3110 3108 … … 3741 3739 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3742 3740 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3743 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3 </a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.5</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3741 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3744 3742 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3745 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.1 9">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a></li>3746 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.1 4">5.3</a></li>3747 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.1 3">5.3</a></li>3743 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a></li> 3744 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3745 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.12">5.3</a></li> 3748 3746 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3749 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a> , <a href="#rfc.xref.Part2.9">3.3</a></li>3750 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.1 8">5.7</a>, <a href="#rfc.xref.Part2.23">6.4.3</a></li>3751 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.2 1">6.4.3</a></li>3747 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li> 3748 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li> 3749 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.20">6.4.3</a></li> 3752 3750 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3753 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.2 4">6.5</a></li>3754 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.2 7">8.6</a></li>3755 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.2 6">8.6</a></li>3756 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2. 10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li>3757 <li><em>Section 8</em> <a href="#rfc.xref.Part2.1 1">4.3.1</a></li>3758 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.1 5">5.6.2</a></li>3759 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.1 6">5.6.2</a></li>3751 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.23">6.5</a></li> 3752 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.26">8.6</a></li> 3753 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.25">8.6</a></li> 3754 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.24">7.4</a></li> 3755 <li><em>Section 8</em> <a href="#rfc.xref.Part2.10">4.3.1</a></li> 3756 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.14">5.6.2</a></li> 3757 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.15">5.6.2</a></li> 3760 3758 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3761 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.2 2">6.4.3</a></li>3759 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.21">6.4.3</a></li> 3762 3760 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.1">1</a></li> 3763 3761 </ul> 3764 3762 </li> 3765 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.3 </a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>3766 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.1">3.3 </a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>3763 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3764 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.1">3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a></li> 3767 3765 </ul> 3768 3766 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1747 r1750 1103 1103 <x:anchor-alias value="response"/> 1104 1104 <x:anchor-alias value="status-line"/> 1105 <x:anchor-alias value="status-code"/> 1106 <x:anchor-alias value="reason-phrase"/> 1105 1107 <t> 1106 1108 The first line of a response message is the status-line, consisting … … 1116 1118 with a status-line and matches the ABNF rule for HTTP-message. 1117 1119 </t> 1118 1119 <t anchor="status-code"> 1120 The status-code element is a 3-digit integer result code of the attempt to 1121 understand and satisfy the request. See &status-codes; for 1122 further information, such as the list of status codes defined by this 1123 specification, the IANA registry, and considerations for new status codes. 1120 <t> 1121 The status-code element is a 3-digit integer code describing the 1122 result of the server's attempt to understand and satisfy the client's 1123 corresponding request. The rest of the response message is to be 1124 interpreted in light of the semantics defined for that status code. 1125 See &status-codes; for information about the semantics of status codes, 1126 including the classes of status code (indicated by the first digit), 1127 the status codes defined by this specification, considerations for the 1128 definition of new status codes, and the IANA registry. 1124 1129 </t> 1125 1130 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="status-code"/> 1126 1131 <x:ref>status-code</x:ref> = 3<x:ref>DIGIT</x:ref> 1127 1132 </artwork></figure> 1128 1129 <t anchor="reason-phrase"> 1133 <t> 1130 1134 The reason-phrase element exists for the sole purpose of providing a 1131 1135 textual description associated with the numeric status code, mostly … … 1498 1502 The presence of a message body in a response depends on both 1499 1503 the request method to which it is responding and the response 1500 status code (<xref target="status -code"/>).1504 status code (<xref target="status.line"/>). 1501 1505 Responses to the HEAD request method never include a message body 1502 1506 because the associated response header fields (e.g., … … 1508 1512 <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body. 1509 1513 All other responses do include a message body, although the body 1510 &MAY; be of zero length. (See &status-codes; and &status-304;.)1514 &MAY; be of zero length. 1511 1515 </t> 1512 1516
Note: See TracChangeset
for help on using the changeset viewer.