Changeset 2055 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 17/12/12 07:14:12 (10 years ago)
- File:
-
- 1 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>
Note: See TracChangeset
for help on using the changeset viewer.