Changeset 2055
- Timestamp:
- 17/12/12 07:14:12 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2054 r2055 1657 1657 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a <a href="#status.4xx" class="smpl">4xx</a> status code other than 417. 1658 1658 </p> 1659 <p id="rfc.section.5.1.2.p.4">The only expectation defined by this specification is:</p> 1660 <p id="rfc.section.5.1.2.p.5"><span id="rfc.iref.46"></span><span id="rfc.iref.e.2"></span> 100-continue 1659 <p id="rfc.section.5.1.2.p.4">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 1660 <p id="rfc.section.5.1.2.p.5">The Expect header field <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1661 </p> 1662 <p id="rfc.section.5.1.2.p.6">Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect header field.</p> 1663 <div id="rfc.iref.46"></div> 1664 <div id="rfc.iref.e.2"></div> 1665 <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4> 1666 <p id="rfc.section.5.1.2.1.p.1">The only expectation defined by this specification is:</p> 1667 <p id="rfc.section.5.1.2.1.p.2"> <dfn>100-continue</dfn> 1661 1668 </p> 1662 1669 <ul class="empty"> 1663 <li>The "100-continue" expectation is defined below. It does not support any expect-params.</li> 1670 <li>The request includes a payload body and the client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response after sending the request header section but before sending the payload body. The 100-continue expectation does not 1671 use any expect-params. 1672 </li> 1664 1673 </ul> 1665 <p id="rfc.section.5.1.2.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 1666 <p id="rfc.section.5.1.2.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 1667 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1668 </p> 1669 <p id="rfc.section.5.1.2.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 1670 <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4> 1671 <p id="rfc.section.5.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept 1674 <p id="rfc.section.5.1.2.1.p.3">The primary purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept 1672 1675 the request (based on the request header fields) before the client sends the payload body. In some cases, it might either 1673 1676 be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without 1674 1677 looking at the body. 1675 1678 </p> 1676 <p id="rfc.section.5.1.2.1.p. 2">Requirements for HTTP/1.1 clients: </p>1679 <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 clients: </p> 1677 1680 <ul> 1678 1681 <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the payload body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. … … 1681 1684 </li> 1682 1685 </ul> 1683 <p id="rfc.section.5.1.2.1.p. 3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:1686 <p id="rfc.section.5.1.2.1.p.5">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 1684 1687 100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has 1685 1688 never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body. 1686 1689 </p> 1687 <p id="rfc.section.5.1.2.1.p. 4">Requirements for HTTP/1.1 origin servers: </p>1690 <p id="rfc.section.5.1.2.1.p.6">Requirements for HTTP/1.1 origin servers: </p> 1688 1691 <ul> 1689 1692 <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request. … … 1705 1708 </li> 1706 1709 </ul> 1707 <p id="rfc.section.5.1.2.1.p. 5">Requirements for HTTP/1.1 proxies: </p>1710 <p id="rfc.section.5.1.2.1.p.7">Requirements for HTTP/1.1 proxies: </p> 1708 1711 <ul> 1709 1712 <li>If a proxy receives a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 … … 2104 2107 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="status.codes" href="#status.codes">Response Status Codes</a></h1> 2105 2108 <p id="rfc.section.6.p.1">The status-code element is a 3-digit integer code giving the result of the attempt to understand and satisfy the request.</p> 2106 <p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, 2107 though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent 2108 to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was 2109 something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the representation enclosed with the response, since that representation is likely to include human-readable 2110 information which will explain the unusual status. 2111 </p> 2112 <p id="rfc.section.6.p.3">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. 2109 <p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, 2110 though such understanding is obviously desirable. However, clients <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent 2111 to the x00 status code of that class, with the exception that a response with an unrecognized status code <em class="bcp14">MUST NOT</em> be cached. 2112 </p> 2113 <p id="rfc.section.6.p.3">For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something 2114 wrong with its request and treat the response as if it had received a 400 status code. If the response includes a message 2115 body, it will usually include a representation that explains the response status. 2116 </p> 2117 <p id="rfc.section.6.p.4">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. 2113 2118 There are 5 values for the first digit: 2114 2119 </p> … … 2125 2130 </li> 2126 2131 </ul> 2127 <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3.1.1.5</a>).2128 </p>2129 2132 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> 2130 2133 <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the … … 2366 2369 <div id="rfc.iref.71"></div> 2367 2370 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> 2368 <p id="rfc.section.6.2.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 2369 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 2370 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 5.1.2.1</a> for detailed discussion of the use and handling of this status code. 2371 <p id="rfc.section.6.2.1.p.1">The <dfn>100 (Continue)</dfn> status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The 2372 server intends to send a final response after the request has been fully received and acted upon. 2373 </p> 2374 <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#use.of.the.100.status" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 5.1.2.1</a>. The client ought to continue sending the request and discard the 100 response. 2375 </p> 2376 <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#use.of.the.100.status" class="smpl">100-continue</a> expectation, the client can simply discard this interim response. 2371 2377 </p> 2372 2378 <div id="rfc.iref.71"></div> 2373 2379 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 2374 <p id="rfc.section.6.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined2375 bythe response's Upgrade header field immediately after the empty line which terminates the 101 response.2376 </p> 2377 <p id="rfc.section.6.2.2.p.2"> The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over2378 older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use2379 such features.2380 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated 2381 within the response's Upgrade header field immediately after the empty line which terminates the 101 response. 2382 </p> 2383 <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching 2384 to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might 2385 be advantageous when delivering resources that use such features. 2380 2386 </p> 2381 2387 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> … … 2385 2391 <div id="rfc.iref.72"></div> 2386 2392 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 2387 <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload sent in the response is dependent on the method used in the request, for example: </p> 2393 <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The payload sent in the response is dependent on the method used in 2394 the request, for example: 2395 </p> 2388 2396 <dl> 2389 2397 <dt>GET</dt> … … 2400 2408 <div id="rfc.iref.72"></div> 2401 2409 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> 2402 <p id="rfc.section.6.3.2.p.1">The request has been fulfilled and has resulted in one or more new resources being created.</p> 2410 <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. 2411 </p> 2403 2412 <p id="rfc.section.6.3.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in 2404 the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted 2405 (e.g., in the case of a response to a PUT request). 2406 </p> 2407 <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before sending the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead. 2408 </p> 2409 <p id="rfc.section.6.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by 2410 the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). 2413 the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the effective request URI, the Location field can be omitted. 2414 </p> 2415 <p id="rfc.section.6.3.2.p.3">If an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field is present in a 201 response, its field value is the entity-tag for the representation created, which is the 2416 new representation of the resource identified by either the <a href="#header.location" class="smpl">Location</a> header field or, if no Location header field is received, by the effective request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). 2411 2417 </p> 2412 2418 <div id="rfc.iref.72"></div> 2413 2419 <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> 2414 <p id="rfc.section.6.3.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually2415 be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status2416 code from an asynchronous operation such as this.2420 <p id="rfc.section.6.3.3.p.1">The <dfn>202 (Accepted)</dfn> status code indicates that the request has been accepted for processing, but the processing has not been completed. The request 2421 might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility 2422 for re-sending a status code from an asynchronous operation such as this. 2417 2423 </p> 2418 2424 <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process 2419 2425 (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the 2420 server persist until the process is completed. The representation sent with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the2421 user can expect the request to be fulfilled.2426 server persist until the process is completed. The representation sent with this response ought to describe the request's 2427 current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. 2422 2428 </p> 2423 2429 <div id="rfc.iref.72"></div> 2424 2430 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 2425 <p id="rfc.section.6.3.4.p.1">The request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might2431 <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might 2426 2432 impact later decisions regarding the content. For example, future cache validation requests for the content might only be 2427 2433 applicable along the same request path (through the same proxies). … … 2431 2437 <div id="rfc.iref.72"></div> 2432 2438 <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 2433 <p id="rfc.section.6.3.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional2434 content to send in the response payload body. Metadata in the response header fields refer to the target resource and its2435 current representationafter the requested action.2439 <p id="rfc.section.6.3.5.p.1">The <dfn>204 (No Content)</dfn> status code indicates that the server has successfully fulfilled the request and that there is no additional content to send 2440 in the response payload body. Metadata in the response header fields refer to the target resource and its current representation 2441 after the requested action. 2436 2442 </p> 2437 2443 <p id="rfc.section.6.3.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that 2438 2444 target resource. 2439 2445 </p> 2440 <p id="rfc.section.6.3.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying2441 that the user agent <em class="bcp14">SHOULD NOT</em> traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication2442 of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the2443 active representation.2446 <p id="rfc.section.6.3.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying 2447 that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the 2448 user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or 2449 updated metadata in the response to the active representation. 2444 2450 </p> 2445 2451 <p id="rfc.section.6.3.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that … … 2447 2453 automated data transfers to be prevalent, such as within distributed version control systems. 2448 2454 </p> 2449 <p id="rfc.section.6.3.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. 2450 </p> 2455 <p id="rfc.section.6.3.5.p.5">A 204 response does not include a message body, and thus is always terminated by the first empty line after the header fields.</p> 2451 2456 <div id="rfc.iref.72"></div> 2452 2457 <h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> 2453 <p id="rfc.section.6.3.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions 2454 to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate 2455 another input action. 2456 </p> 2457 <p id="rfc.section.6.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 2458 <p id="rfc.section.6.3.6.p.1">The <dfn>205 (Reset Content)</dfn> status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", 2459 which caused the request to be sent, to its original state as received from the origin server. 2460 </p> 2461 <p id="rfc.section.6.3.6.p.2">This response is intended to support a common data entry use case where the user receives content that supports data entry 2462 (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, 2463 and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action. 2464 </p> 2465 <p id="rfc.section.6.3.6.p.3">Since the 205 status code implies that no additional content will be provided in the payload, the server <em class="bcp14">MUST</em> send a message body of zero length. In other words, the server <em class="bcp14">MUST</em> send a "Content-Length: 0" field in a 205 response or close the connection immediately after sending the blank line terminating 2466 the header section. 2458 2467 </p> 2459 2468 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2689 2698 <div id="rfc.iref.74"></div> 2690 2699 <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2691 <p id="rfc.section.6.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols.2700 <p id="rfc.section.6.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols. 2692 2701 </p> 2693 2702 <div id="rfc.figure.u.41"></div> … … 2748 2757 <p id="rfc.section.6.6.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2749 2758 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2750 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2759 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2751 2760 </p> 2752 2761 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2753 2762 <p id="rfc.section.7.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 2754 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).2763 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 2755 2764 </p> 2756 2765 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 3068 3077 </p> 3069 3078 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.61"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) ) 3070 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers3079 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers 3071 3080 are listed in order of their significance for identifying the origin server software. Each product identifier consists of 3072 3081 a name and optional version, as defined in <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 5.5.3</a>. … … 3101 3110 to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3102 3111 </p> 3103 <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the3112 <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the 3104 3113 parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of 3105 3114 new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a … … 3442 3451 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3443 3452 <p id="rfc.section.8.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, 3444 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.3453 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3445 3454 </p> 3446 3455 <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name … … 3449 3458 processing, since the prefix would ensure that private names never collide with a newly registered Internet name.) 3450 3459 </p> 3451 <p id="rfc.section.8.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3460 <p id="rfc.section.8.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3452 3461 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 3453 3462 </p> 3454 3463 <p id="rfc.section.8.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 3455 3464 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 3456 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3465 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3457 3466 </p> 3458 3467 <p id="rfc.section.8.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 3465 3474 double-quotes will likely cause unnecessary confusion. 3466 3475 </p> 3467 <p id="rfc.section.8.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type. 4" title="Content-Type">Section 3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing3476 <p id="rfc.section.8.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 3468 3477 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 3469 3478 it (for an example, see the notes on parameter handling for media types in <a href="#media.type" title="Media Type">Section 3.1.1.1</a>). … … 3472 3481 <ul> 3473 3482 <li> 3474 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3483 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3475 3484 </p> 3476 3485 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 3488 3497 </li> 3489 3498 <li> 3490 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3499 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3491 3500 </p> 3492 3501 </li> … … 3499 3508 </li> 3500 3509 <li> 3501 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3510 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3502 3511 </p> 3503 3512 </li> … … 3580 3589 <td class="left">http</td> 3581 3590 <td class="left">standard</td> 3582 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type. 5" title="Content-Type">Section 3.1.1.5</a>3591 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 3.1.1.5</a> 3583 3592 </td> 3584 3593 </tr> … … 3665 3674 <p id="rfc.section.8.3.2.p.2">The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 3666 3675 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h2> 3667 <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.3676 <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3668 3677 </p> 3669 3678 <h3 id="rfc.section.8.4.1"><a href="#rfc.section.8.4.1">8.4.1</a> <a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3> … … 3675 3684 <li>Pointer to specification text</li> 3676 3685 </ul> 3677 <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3686 <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3678 3687 </p> 3679 3688 <p id="rfc.section.8.4.1.p.3">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.3"><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 content coding defined in this section. … … 3695 3704 <td class="left">compress</td> 3696 3705 <td class="left">UNIX "compress" program method</td> 3697 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3706 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3698 3707 </td> 3699 3708 </tr> … … 3702 3711 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 3703 3712 </td> 3704 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1. 40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3713 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3705 3714 </td> 3706 3715 </tr> … … 3708 3717 <td class="left">gzip</td> 3709 3718 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 3710 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3719 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3711 3720 </td> 3712 3721 </tr> … … 3800 3809 </p> 3801 3810 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 3802 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3811 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3803 3812 </p> 3804 3813 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 4138 4147 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 7.4.1</a>) 4139 4148 </p> 4140 <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.4.2</a>)4149 <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.4.2</a>) 4141 4150 </p> 4142 4151 <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) … … 4163 4172 (any visible US-ASCII character). 4164 4173 </p> 4165 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:4166 </p> 4167 <div id="rfc.figure.u.64"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4168 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4169 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4170 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.4 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4171 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.4 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4172 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1. 50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4173 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>4174 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4175 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4176 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4177 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4174 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 4175 </p> 4176 <div id="rfc.figure.u.64"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4177 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4178 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4179 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4180 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4181 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4182 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 4183 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4184 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4185 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4186 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4178 4187 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4179 4188 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4336 4345 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4337 4346 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5.1.2.1</a>, <a href="#rfc.xref.status.100.2">5.1.2.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.71"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">8.2.3</a></li> 4338 <li>100-continue (expect value) <a href="#rfc.iref.46"><b>5.1.2 </b></a></li>4347 <li>100-continue (expect value) <a href="#rfc.iref.46"><b>5.1.2.1</b></a></li> 4339 4348 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.71"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li> 4340 4349 <li>1xx Informational (status code class) <a href="#rfc.iref.70"><b>6.2</b></a></li> … … 4414 4423 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.7"><b>3.1.4.2</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.2</a>, <a href="#rfc.xref.header.content-location.4">8.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4415 4424 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.10">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4416 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">3.1.1.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1.5</b></a>, <a href="#rfc.xref.header.content-type.3"> 6</a>, <a href="#rfc.xref.header.content-type.4">8.3.1</a>, <a href="#rfc.xref.header.content-type.5">8.3.2</a></li>4425 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">3.1.1.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1.5</b></a>, <a href="#rfc.xref.header.content-type.3">8.3.1</a>, <a href="#rfc.xref.header.content-type.4">8.3.2</a></li> 4417 4426 </ul> 4418 4427 </li> … … 4427 4436 <li>Expect Values 4428 4437 <ul> 4429 <li>100-continue <a href="#rfc.iref.e.2"><b>5.1.2 </b></a></li>4438 <li>100-continue <a href="#rfc.iref.e.2"><b>5.1.2.1</b></a></li> 4430 4439 </ul> 4431 4440 </li> … … 4527 4536 </li> 4528 4537 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4529 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6. 3.6</a>, <a href="#rfc.xref.Part1.25">6.5.15</a>, <a href="#rfc.xref.Part1.26">6.6.6</a>, <a href="#rfc.xref.Part1.27">7</a>, <a href="#rfc.xref.Part1.28">7.4.2</a>, <a href="#rfc.xref.Part1.29">8.1.2</a>, <a href="#rfc.xref.Part1.30">8.3.1</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.4</a>, <a href="#rfc.xref.Part1.37">8.4.1</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.2</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>4538 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.15</a>, <a href="#rfc.xref.Part1.25">6.6.6</a>, <a href="#rfc.xref.Part1.26">7</a>, <a href="#rfc.xref.Part1.27">7.4.2</a>, <a href="#rfc.xref.Part1.28">8.1.2</a>, <a href="#rfc.xref.Part1.29">8.3.1</a>, <a href="#rfc.xref.Part1.30">8.3.1</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.4</a>, <a href="#rfc.xref.Part1.36">8.4.1</a>, <a href="#rfc.xref.Part1.37">8.4.1</a>, <a href="#rfc.xref.Part1.38">8.4.2</a>, <a href="#rfc.xref.Part1.39">8.4.2</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.42">C</a>, <a href="#rfc.xref.Part1.43">D</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a><ul> 4530 4539 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 4531 4540 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 4532 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.2 6">6.6.6</a></li>4533 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.4 8">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.52">D</a></li>4534 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.2 8">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.51">D</a></li>4535 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4 5">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a></li>4536 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.3 2">8.3.1</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>4541 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.25">6.6.6</a></li> 4542 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.51">D</a></li> 4543 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.27">7.4.2</a>, <a href="#rfc.xref.Part1.29">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.50">D</a></li> 4544 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a></li> 4545 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a></li> 4537 4546 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li> 4538 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.2 4">6.3.6</a>, <a href="#rfc.xref.Part1.29">8.1.2</a></li>4547 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.28">8.1.2</a></li> 4539 4548 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.13">3.3</a></li> 4540 <li><em>Section 4</em> <a href="#rfc.xref.Part1.3 7">8.4.1</a></li>4541 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.3 5">8.3.1</a></li>4542 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.3 9">8.4.2</a></li>4543 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.3 6">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a></li>4544 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1. 40">8.4.2</a></li>4545 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.4 1">8.4.2</a></li>4549 <li><em>Section 4</em> <a href="#rfc.xref.Part1.36">8.4.1</a></li> 4550 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.34">8.3.1</a></li> 4551 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.38">8.4.2</a></li> 4552 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.35">8.4</a>, <a href="#rfc.xref.Part1.37">8.4.1</a></li> 4553 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.39">8.4.2</a></li> 4554 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a></li> 4546 4555 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">5.5</a></li> 4547 4556 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a></li> 4548 4557 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 4549 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.2 7">7</a></li>4550 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.4 3">C</a></li>4558 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.26">7</a></li> 4559 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.42">C</a></li> 4551 4560 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.23">6.3.4</a></li> 4552 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.3 4">8.3.1</a></li>4553 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.2 5">6.5.15</a></li>4561 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.33">8.3.1</a></li> 4562 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.5.15</a></li> 4554 4563 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a></li> 4555 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 2">10</a></li>4556 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.3 1">8.3.1</a></li>4564 <li><em>Section 9</em> <a href="#rfc.xref.Part1.41">10</a></li> 4565 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.30">8.3.1</a></li> 4557 4566 </ul> 4558 4567 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2054 r2055 1789 1789 </t> 1790 1790 <t> 1791 The only expectation defined by this specification is: 1792 </t> 1793 <t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/> 1794 100-continue 1791 Comparison is case-insensitive for names (expect-name), and case-sensitive 1792 for values (expect-value). 1793 </t> 1794 <t> 1795 The Expect header field &MUST; be forwarded if the request is forwarded. 1796 </t> 1797 <t> 1798 Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect 1799 header field. 1800 </t> 1801 1802 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status"> 1803 <iref primary="true" item="100-continue (expect value)"/> 1804 <iref primary="true" item="Expect Values" subitem="100-continue"/> 1805 <x:anchor-alias value="100-continue"/> 1806 <t> 1807 The only expectation defined by this specification is: 1808 </t> 1809 <t> 1810 <x:dfn>100-continue</x:dfn> 1795 1811 <list> 1796 1812 <t> 1797 The "100-continue" expectation is defined below. It does not support 1798 any expect-params. 1813 The request includes a payload body and the client will wait for a 1814 <x:ref>100 (Continue)</x:ref> response after sending the request 1815 header section but before sending the payload body. 1816 The 100-continue expectation does not use any expect-params. 1799 1817 </t> 1800 1818 </list> 1801 1819 </t> 1802 1820 <t> 1803 Comparison is case-insensitive for names (expect-name), and case-sensitive 1804 for values (expect-value). 1805 </t> 1806 <t> 1807 The Expect mechanism is hop-by-hop: the above requirements apply to any 1808 server, including proxies. However, the Expect header field itself is 1809 end-to-end; it &MUST; be forwarded if the request is forwarded. 1810 </t> 1811 <t> 1812 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect 1813 header field. 1814 </t> 1815 1816 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status"> 1817 <t> 1818 The purpose of the <x:ref>100 (Continue)</x:ref> status code 1821 The primary purpose of the <x:ref>100 (Continue)</x:ref> status code 1819 1822 (<xref target='status.100'/>) 1820 1823 is to allow a client that is sending a request message with a payload … … 2469 2472 </t> 2470 2473 <t> 2471 HTTP status codes are extensible. HTTP applications are not required2474 HTTP status codes are extensible. HTTP clients are not required 2472 2475 to understand the meaning of all registered status codes, though such 2473 understanding is obviously desirable. However, applications &MUST;2476 understanding is obviously desirable. However, clients &MUST; 2474 2477 understand the class of any status code, as indicated by the first 2475 digit, and treat any unrecognized response as being equivalent to the 2476 x00 status code of that class, with the exception that an 2477 unrecognized response &MUST-NOT; be cached. For example, if an 2478 unrecognized status code of 431 is received by the client, it can 2479 safely assume that there was something wrong with its request and 2480 treat the response as if it had received a 400 status code. In such 2481 cases, user agents &SHOULD; present to the user the representation enclosed 2482 with the response, since that representation is likely to include human-readable 2483 information which will explain the unusual status. 2478 digit, and treat an unrecognized status code as being equivalent to the 2479 x00 status code of that class, with the exception that a response with an 2480 unrecognized status code &MUST-NOT; be cached. 2481 </t> 2482 <t> 2483 For example, if an unrecognized status code of 471 is received by a client, 2484 the client can assume that there was something wrong with its request and 2485 treat the response as if it had received a 400 status code. If the response 2486 includes a message body, it will usually include a representation that 2487 explains the response status. 2484 2488 </t> 2485 2489 <t> … … 2510 2514 </list> 2511 2515 </t> 2512 <t>2513 For most status codes the response can carry a payload, in which case a2514 <x:ref>Content-Type</x:ref> header field indicates the payload's media type2515 (&header-content-type;).2516 </t>2517 2516 2518 2517 <section title="Overview of Status Codes" anchor="overview.of.status.codes"> … … 2612 2611 <x:anchor-alias value="100 (Continue)"/> 2613 2612 <t> 2614 The client &SHOULD; continue with its request. This interim response is 2615 used to inform the client that the initial part of the request has 2616 been received and has not yet been rejected by the server. The client 2617 &SHOULD; continue by sending the remainder of the request or, if the 2618 request has already been completed, ignore this response. The server 2619 &MUST; send a final response after the request has been completed. 2620 See <xref target="use.of.the.100.status"/> for detailed discussion of the 2621 use and handling of this status code. 2613 The <x:dfn>100 (Continue)</x:dfn> status code indicates that the initial 2614 part of a request has been received and has not yet been rejected by the 2615 server. The server intends to send a final response after the request has 2616 been fully received and acted upon. 2617 </t> 2618 <t> 2619 When the request contains an <x:ref>Expect</x:ref> header field that 2620 includes a <x:ref>100-continue</x:ref> expectation, the 100 response 2621 indicates that the server wishes to receive the request payload body, 2622 as described in <xref target="use.of.the.100.status"/>. The client 2623 ought to continue sending the request and discard the 100 response. 2624 </t> 2625 <t> 2626 If the request did not contain an <x:ref>Expect</x:ref> header field 2627 containing the <x:ref>100-continue</x:ref> expectation, 2628 the client can simply discard this interim response. 2622 2629 </t> 2623 2630 </section> … … 2627 2634 <x:anchor-alias value="101 (Switching Protocols)"/> 2628 2635 <t> 2629 The server understands and is willing to comply with the client's request, 2630 via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for 2636 The <x:dfn>101 (Switching Protocols)</x:dfn> status code indicates that the 2637 server understands and is willing to comply with the client's request, 2638 via the <x:ref>Upgrade</x:ref> header field (&header-upgrade;), for 2631 2639 a change in the application protocol being used on this connection. The 2632 server will switch protocols to those defined by the response's Upgrade2633 header field immediately after the empty line which terminates the 1012634 response.2635 </t> 2636 <t> 2637 The protocol &SHOULD; be switched only when it is advantageous to do2638 so. For example, switching to a newer version of HTTP is advantageous2639 over older versions, and switching to a real-time, synchronous2640 protocol might be advantageous when delivering resources that use2641 such features.2640 server will switch to the protocol(s) indicated within the response's 2641 Upgrade header field immediately after the empty line which terminates the 2642 101 response. 2643 </t> 2644 <t> 2645 It is assumed that the server will only agree to switch protocols when 2646 it is advantageous to do so. For example, switching to a newer version of 2647 HTTP might be advantageous over older versions, and switching to a 2648 real-time, synchronous protocol might be advantageous when delivering 2649 resources that use such features. 2642 2650 </t> 2643 2651 </section> … … 2658 2666 <x:anchor-alias value="200 (OK)"/> 2659 2667 <t> 2660 The request has succeeded. The payload sent in the response 2668 The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has 2669 succeeded. The payload sent in the response 2661 2670 is dependent on the method used in the request, for example: 2662 2671 <list style="hanging"> … … 2686 2695 <x:anchor-alias value="201 (Created)"/> 2687 2696 <t> 2688 The request has been fulfilled and has resulted in one or more new resources2689 be ing created.2697 The <x:dfn>201 (Created)</x:dfn> status code indicates that the request has 2698 been fulfilled and has resulted in one or more new resources being created. 2690 2699 </t> 2691 2700 <t> … … 2693 2702 with the most relevant URI also being carried in the <x:ref>Location</x:ref> 2694 2703 header field. If the newly created resource's URI is the same as the 2695 Effective Request URI, this information can be omitted (e.g., in the case of 2696 a response to a PUT request). 2697 </t> 2698 <t> 2699 The origin server &MUST; create the resource(s) before sending the 201 status 2700 code. If the action cannot be carried out immediately, the server &SHOULD; 2701 respond with a <x:ref>202 (Accepted)</x:ref> response instead. 2702 </t> 2703 <t> 2704 A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field 2705 indicating the current value of the entity-tag for the representation of the 2706 resource identified by the <x:ref>Location</x:ref> header field or, in case 2707 the Location header field was omitted, by the Effective Request URI (see 2708 &header-etag;). 2704 effective request URI, the Location field can be omitted. 2705 </t> 2706 <t> 2707 If an <x:ref>ETag</x:ref> header field is present in a 201 response, its 2708 field value is the entity-tag for the representation created, which 2709 is the new representation of the resource identified by either the 2710 <x:ref>Location</x:ref> header field or, if no Location header field 2711 is received, by the effective request URI (see &header-etag;). 2709 2712 </t> 2710 2713 </section> … … 2714 2717 <x:anchor-alias value="202 (Accepted)"/> 2715 2718 <t> 2716 The request has been accepted for processing, but the processing has 2717 not been completed. The request might or might not eventually be 2718 acted upon, as it might be disallowed when processing actually takes 2719 place. There is no facility for re-sending a status code from an 2720 asynchronous operation such as this. 2719 The <x:dfn>202 (Accepted)</x:dfn> status code indicates that the request 2720 has been accepted for processing, but the processing has not been 2721 completed. The request might or might not eventually be acted upon, as it 2722 might be disallowed when processing actually takes place. There is no 2723 facility for re-sending a status code from an asynchronous operation such 2724 as this. 2721 2725 </t> 2722 2726 <t> … … 2726 2730 requiring that the user agent's connection to the server persist 2727 2731 until the process is completed. The representation sent with this 2728 response &SHOULD; include an indication ofthe request's current status2732 response ought to describe the request's current status 2729 2733 and either a pointer to a status monitor or some estimate of when the 2730 2734 user can expect the request to be fulfilled. … … 2736 2740 <x:anchor-alias value="203 (Non-Authoritative Information)"/> 2737 2741 <t> 2738 The request was successful but the enclosed payload has been modified 2739 from that of the origin server's <x:ref>200 (OK)</x:ref> response by a 2740 transforming proxy (&transformations;). This status code allows the proxy 2741 to notify recipients when a transformation has been applied, since that 2742 knowledge might impact later decisions regarding the content. 2743 For example, future cache validation requests for the content might only 2744 be applicable along the same request path (through the same proxies). 2742 The <x:dfn>203 (Non-Authoritative Information)</x:dfn> status code 2743 indicates that the request was successful but the enclosed payload has been 2744 modified from that of the origin server's <x:ref>200 (OK)</x:ref> response 2745 by a transforming proxy (&transformations;). This status code allows the 2746 proxy to notify recipients when a transformation has been applied, since 2747 that knowledge might impact later decisions regarding the content. For 2748 example, future cache validation requests for the content might only be 2749 applicable along the same request path (through the same proxies). 2745 2750 </t> 2746 2751 <t> … … 2755 2760 <x:anchor-alias value="204 (No Content)"/> 2756 2761 <t> 2757 The 204 (No Content) status code indicates that the server has2758 successfully fulfilled the request and that there is no additional2759 content to send in the response payload body. Metadata in the2760 response header fields refer to the target resource and its current2761 representationafter the requested action.2762 The <x:dfn>204 (No Content)</x:dfn> status code indicates that the server 2763 has successfully fulfilled the request and that there is no additional 2764 content to send in the response payload body. Metadata in the response 2765 header fields refer to the target resource and its current representation 2766 after the requested action. 2762 2767 </t> 2763 2768 <t> … … 2769 2774 <t> 2770 2775 The 204 response allows a server to indicate that the action has been 2771 successfully applied to the target resource while implying that the2772 user agent &SHOULD-NOT;traverse away from its current "document view"2776 successfully applied to the target resource, while implying that the 2777 user agent does not need to traverse away from its current "document view" 2773 2778 (if any). The server assumes that the user agent will provide some 2774 2779 indication of the success to its user, in accord with its own interface, … … 2784 2789 </t> 2785 2790 <t> 2786 The 204 response &MUST-NOT;include a message body, and thus is always2791 A 204 response does not include a message body, and thus is always 2787 2792 terminated by the first empty line after the header fields. 2788 2793 </t> … … 2792 2797 <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/> 2793 2798 <t> 2794 The server has fulfilled the request and the user agent &SHOULD; reset 2795 the document view which caused the request to be sent. This response 2796 is primarily intended to allow input for actions to take place via 2797 user input, followed by a clearing of the form in which the input is 2798 given so that the user can easily initiate another input action. 2799 The <x:dfn>205 (Reset Content)</x:dfn> status code indicates that the 2800 server has fulfilled the request and desires that the user agent reset the 2801 "document view", which caused the request to be sent, to its original state 2802 as received from the origin server. 2799 2803 </t> 2800 2804 <t> 2801 The message body included with the response &MUST; be empty. Note that 2802 receivers still need to parse the response according to the algorithm defined 2803 in &message-body;. 2805 This response is intended to support a common data entry use case where 2806 the user receives content that supports data entry (a form, notepad, 2807 canvas, etc.), enters or manipulates data in that space, causes the entered 2808 data to be submitted in a request, and then the data entry mechanism is 2809 reset for the next entry so that the user can easily initiate another 2810 input action. 2811 </t> 2812 <t> 2813 Since the 205 status code implies that no additional content will be 2814 provided in the payload, the server &MUST; send a message body of zero 2815 length. In other words, the server &MUST; send a "Content-Length: 0" field 2816 in a 205 response or close the connection immediately after sending the 2817 blank line terminating the header section. 2804 2818 </t> 2805 2819 </section>
Note: See TracChangeset
for help on using the changeset viewer.