Ignore:
Timestamp:
Dec 16, 2012, 11:14:12 PM (7 years ago)
Author:
fielding@…
Message:

editorial improvements to 1xx and 2xx status codes; partly addresses #419

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2054 r2055  
    16571657         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.
    16581658      </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>&nbsp;<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> 
    16611668      </p>
    16621669      <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>
    16641673      </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>&nbsp;<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&nbsp;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&nbsp;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
    16721675         the request (based on the request header fields) before the client sends the payload body. In some cases, it might either
    16731676         be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without
    16741677         looking at the body.
    16751678      </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>
    16771680      <ul>
    16781681         <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.
    … …  
    16811684         </li>
    16821685      </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:
    16841687         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
    16851688         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.
    16861689      </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>
    16881691      <ul>
    16891692         <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.
    … …  
    17051708         </li>
    17061709      </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>
    17081711      <ul>
    17091712         <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
    … …  
    21042107      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="status.codes" href="#status.codes">Response Status Codes</a></h1>
    21052108      <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.
    21132118         There are 5 values for the first digit:
    21142119      </p>
    … …  
    21252130         </li>
    21262131      </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&nbsp;3.1.1.5</a>).
    2128       </p>
    21292132      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    21302133      <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
    … …  
    23662369      <div id="rfc.iref.71"></div>
    23672370      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<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&nbsp;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&nbsp;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.
    23712377      </p>
    23722378      <div id="rfc.iref.71"></div>
    23732379      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<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 defined
    2375          by the 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 over
    2378          older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use
    2379          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.
    23802386      </p>
    23812387      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
    … …  
    23852391      <div id="rfc.iref.72"></div>
    23862392      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<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>
    23882396      <dl>
    23892397         <dt>GET</dt>
    … …  
    24002408      <div id="rfc.iref.72"></div>
    24012409      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<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>
    24032412      <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>).
    24112417      </p>
    24122418      <div id="rfc.iref.72"></div>
    24132419      <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<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 eventually
    2415          be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status
    2416          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.
    24172423      </p>
    24182424      <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
    24192425         (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 the
    2421          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.
    24222428      </p>
    24232429      <div id="rfc.iref.72"></div>
    24242430      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<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 might
     2431      <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
    24262432         impact later decisions regarding the content. For example, future cache validation requests for the content might only be
    24272433         applicable along the same request path (through the same proxies).
    … …  
    24312437      <div id="rfc.iref.72"></div>
    24322438      <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<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 additional
    2434          content to send in the response payload body. Metadata in the response header fields refer to the target resource and its
    2435          current representation after 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.
    24362442      </p>
    24372443      <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
    24382444         target resource.
    24392445      </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 implying
    2441          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 indication
    2442          of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the
    2443          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.
    24442450      </p>
    24452451      <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
    … …  
    24472453         automated data transfers to be prevalent, such as within distributed version control systems.
    24482454      </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>
    24512456      <div id="rfc.iref.72"></div>
    24522457      <h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;<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.
    24582467      </p>
    24592468      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    26892698      <div id="rfc.iref.74"></div>
    26902699      <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<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.25"><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.
    26922701      </p>
    26932702      <div id="rfc.figure.u.41"></div>
    … …  
    27482757      <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
    27492758         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.26"><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.
    27512760      </p>
    27522761      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    27532762      <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.27"><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>).
    27552764      </p>
    27562765      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="response.control.data" href="#response.control.data">Control Data</a></h2>
    … …  
    30683077      </p>
    30693078      <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.28"><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
     3079</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
    30713080         are listed in order of their significance for identifying the origin server software. Each product identifier consists of
    30723081         a name and optional version, as defined in <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;5.5.3</a>.
    … …  
    31013110         to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    31023111      </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.29"><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
     3112      <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
    31043113         parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of
    31053114         new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a
    … …  
    34423451      <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3>
    34433452      <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.
    34453454      </p>
    34463455      <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
    … …  
    34493458         processing, since the prefix would ensure that private names never collide with a newly registered Internet name.)
    34503459      </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.31"><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
     3460      <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
    34523461         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>.
    34533462      </p>
    34543463      <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
    34553464         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.32"><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>).
    34573466      </p>
    34583467      <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
    … …  
    34653474         double-quotes will likely cause unnecessary confusion.
    34663475      </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&nbsp;3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     3476      <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&nbsp;3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    34683477         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    34693478         it (for an example, see the notes on parameter handling for media types in <a href="#media.type" title="Media Type">Section&nbsp;3.1.1.1</a>).
    … …  
    34723481      <ul>
    34733482         <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.33"><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>).
    34753484            </p>
    34763485            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    34883497         </li>
    34893498         <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.34"><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>).
    34913500            </p>
    34923501         </li>
    … …  
    34993508         </li>
    35003509         <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.35"><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>).
    35023511            </p>
    35033512         </li>
    … …  
    35803589                  <td class="left">http</td>
    35813590                  <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&nbsp;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&nbsp;3.1.1.5</a>
    35833592                  </td>
    35843593               </tr>
    … …  
    36653674      <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>
    36663675      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<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.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     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 &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    36683677      </p>
    36693678      <h3 id="rfc.section.8.4.1"><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;<a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3>
    … …  
    36753684         <li>Pointer to specification text</li>
    36763685      </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.37"><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>).
    36783687      </p>
    36793688      <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.
    … …  
    36953704                  <td class="left">compress</td>
    36963705                  <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.39"><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>
    36983707                  </td>
    36993708               </tr>
    … …  
    37023711                  <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>)
    37033712                  </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>
    37053714                  </td>
    37063715               </tr>
    … …  
    37083717                  <td class="left">gzip</td>
    37093718                  <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.41"><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>
    37113720                  </td>
    37123721               </tr>
    … …  
    38003809      </p>
    38013810      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<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.42"><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>.
    38033812      </p>
    38043813      <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References
    … …  
    41384147         trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;7.4.1</a>)
    41394148      </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.43"><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&nbsp;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&nbsp;7.4.2</a>)
    41414150      </p>
    41424151      <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>)
    … …  
    41634172         (any visible US-ASCII character).
    41644173      </p>
    4165       <p id="rfc.section.D.p.2">The rules below are 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>:
    4166       </p>
    4167       <div id="rfc.figure.u.64"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, 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>&gt;
    4168   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, 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>&gt;
    4169   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, 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#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4170   <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, 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>&gt;
    4171   <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4172   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;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>&gt;
    4173   <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, 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#header.fields" title="Header Fields">Section 3.2</a>&gt;
    4174   <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4175   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, 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>&gt;
    4176   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, 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>&gt;
    4177   <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.55"><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>&gt;
     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>           = &lt;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>&gt;
     4177  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;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>&gt;
     4178  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;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>&gt;
     4179  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;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>&gt;
     4180  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;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>&gt;
     4181  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;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>&gt;
     4182  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;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>&gt;
     4183  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;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>&gt;
     4184  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;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>&gt;
     4185  <a href="#imported.abnf" class="smpl">token</a>         = &lt;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>&gt;
     4186  <a href="#imported.abnf" class="smpl">word</a>          = &lt;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>&gt;
    41784187</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    41794188      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    … …  
    43364345            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    43374346                  <li>100 Continue (status code)&nbsp;&nbsp;<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)&nbsp;&nbsp;<a href="#rfc.iref.46"><b>5.1.2</b></a></li>
     4347                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.46"><b>5.1.2.1</b></a></li>
    43394348                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<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>
    43404349                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.70"><b>6.2</b></a></li>
    … …  
    44144423                  <li>Content-Location header field&nbsp;&nbsp;<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>
    44154424                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    44174426               </ul>
    44184427            </li>
    … …  
    44274436                  <li>Expect Values&nbsp;&nbsp;
    44284437                     <ul>
    4429                         <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>5.1.2</b></a></li>
     4438                        <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>5.1.2.1</b></a></li>
    44304439                     </ul>
    44314440                  </li>
    … …  
    45274536            </li>
    45284537            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4529                   <li><em>Part1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    45304539                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    45314540                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    4532                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">6.6.6</a></li>
    4533                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.48">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.28">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">6.6.6</a></li>
     4542                        <li><em>Section 2.7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    45374546                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.3.6</a>, <a href="#rfc.xref.Part1.29">8.1.2</a></li>
     4547                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">8.1.2</a></li>
    45394548                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">3.3</a></li>
    4540                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">8.4.1</a></li>
    4541                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">8.3.1</a></li>
    4542                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.39">8.4.2</a></li>
    4543                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a></li>
    4544                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.41">8.4.2</a></li>
     4549                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">8.4.1</a></li>
     4550                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">8.3.1</a></li>
     4551                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a></li>
    45464555                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.5</a></li>
    45474556                        <li><em>Section 5.3</em>&nbsp;&nbsp;<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>
    45484557                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
    4549                         <li><em>Section 5.5</em>&nbsp;&nbsp;<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.27">7</a></li>
    4550                         <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.43">C</a></li>
     4558                        <li><em>Section 5.5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.42">C</a></li>
    45514560                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.3.4</a></li>
    4552                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">8.3.1</a></li>
    4553                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.25">6.5.15</a></li>
     4561                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a></li>
     4562                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.5.15</a></li>
    45544563                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a></li>
    4555                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">10</a></li>
    4556                         <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">8.3.1</a></li>
     4564                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">10</a></li>
     4565                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.3.1</a></li>
    45574566                     </ul>
    45584567                  </li>
Note: See TracChangeset for help on using the changeset viewer.