Changeset 2055


Ignore:
Timestamp:
17/12/12 07:14:12 (8 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 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>

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

    r2054 r2055  
    17891789</t>
    17901790<t>
    1791    The only expectation defined by this specification is:
    1792 </t>
    1793 <t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/>
    1794   100-continue
     1791   Comparison is case-insensitive for names (expect-name), and case-sensitive
     1792   for values (expect-value).
     1793</t>
     1794<t>
     1795   The Expect header field &MUST; be forwarded if the request is forwarded.
     1796</t>
     1797<t>
     1798   Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect
     1799   header field.
     1800</t>
     1801
     1802<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
     1803  <iref primary="true" item="100-continue (expect value)"/>
     1804  <iref primary="true" item="Expect Values" subitem="100-continue"/>
     1805  <x:anchor-alias value="100-continue"/>
     1806<t>
     1807   The only expectation defined by this specification is:
     1808</t>
     1809<t>
     1810  <x:dfn>100-continue</x:dfn>
    17951811   <list>
    17961812      <t>
    1797         The "100-continue" expectation is defined below. It does not support
    1798         any expect-params.
     1813        The request includes a payload body and the client will wait for a
     1814        <x:ref>100 (Continue)</x:ref> response after sending the request
     1815        header section but before sending the payload body.
     1816        The 100-continue expectation does not use any expect-params.
    17991817      </t>
    18001818   </list>
    18011819</t>
    18021820<t>
    1803    Comparison is case-insensitive for names (expect-name), and case-sensitive
    1804    for values (expect-value).
    1805 </t>
    1806 <t>
    1807    The Expect mechanism is hop-by-hop: the above requirements apply to any
    1808    server, including proxies. However, the Expect header field itself is
    1809    end-to-end; it &MUST; be forwarded if the request is forwarded.
    1810 </t>
    1811 <t>
    1812    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect
    1813    header field.
    1814 </t>
    1815 
    1816 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
    1817 <t>
    1818    The purpose of the <x:ref>100 (Continue)</x:ref> status code
     1821   The primary purpose of the <x:ref>100 (Continue)</x:ref> status code
    18191822   (<xref target='status.100'/>)
    18201823   is to allow a client that is sending a request message with a payload
    … …  
    24692472</t>
    24702473<t>
    2471    HTTP status codes are extensible. HTTP applications are not required
     2474   HTTP status codes are extensible. HTTP clients are not required
    24722475   to understand the meaning of all registered status codes, though such
    2473    understanding is obviously desirable. However, applications &MUST;
     2476   understanding is obviously desirable. However, clients &MUST;
    24742477   understand the class of any status code, as indicated by the first
    2475    digit, and treat any unrecognized response as being equivalent to the
    2476    x00 status code of that class, with the exception that an
    2477    unrecognized response &MUST-NOT; be cached. For example, if an
    2478    unrecognized status code of 431 is received by the client, it can
    2479    safely assume that there was something wrong with its request and
    2480    treat the response as if it had received a 400 status code. In such
    2481    cases, user agents &SHOULD; present to the user the representation enclosed
    2482    with the response, since that representation is likely to include human-readable
    2483    information which will explain the unusual status.
     2478   digit, and treat an unrecognized status code as being equivalent to the
     2479   x00 status code of that class, with the exception that a response with an
     2480   unrecognized status code &MUST-NOT; be cached.
     2481</t>
     2482<t>
     2483   For example, if an unrecognized status code of 471 is received by a client,
     2484   the client can assume that there was something wrong with its request and
     2485   treat the response as if it had received a 400 status code. If the response
     2486   includes a message body, it will usually include a representation that
     2487   explains the response status.
    24842488</t>
    24852489<t>
    … …  
    25102514  </list>
    25112515</t>
    2512 <t>
    2513    For most status codes the response can carry a payload, in which case a
    2514    <x:ref>Content-Type</x:ref> header field indicates the payload's media type
    2515    (&header-content-type;).
    2516 </t>
    25172516
    25182517<section title="Overview of Status Codes" anchor="overview.of.status.codes">
    … …  
    26122611  <x:anchor-alias value="100 (Continue)"/>
    26132612<t>
    2614    The client &SHOULD; continue with its request. This interim response is
    2615    used to inform the client that the initial part of the request has
    2616    been received and has not yet been rejected by the server. The client
    2617    &SHOULD; continue by sending the remainder of the request or, if the
    2618    request has already been completed, ignore this response. The server
    2619    &MUST; send a final response after the request has been completed.
    2620    See <xref target="use.of.the.100.status"/> for detailed discussion of the
    2621    use and handling of this status code.
     2613   The <x:dfn>100 (Continue)</x:dfn> status code indicates that the initial
     2614   part of a request has been received and has not yet been rejected by the
     2615   server. The server intends to send a final response after the request has
     2616   been fully received and acted upon.
     2617</t>
     2618<t>
     2619   When the request contains an <x:ref>Expect</x:ref> header field that
     2620   includes a <x:ref>100-continue</x:ref> expectation, the 100 response
     2621   indicates that the server wishes to receive the request payload body,
     2622   as described in <xref target="use.of.the.100.status"/>.  The client
     2623   ought to continue sending the request and discard the 100 response.
     2624</t>
     2625<t>
     2626   If the request did not contain an <x:ref>Expect</x:ref> header field
     2627   containing the <x:ref>100-continue</x:ref> expectation,
     2628   the client can simply discard this interim response.
    26222629</t>
    26232630</section>
    … …  
    26272634  <x:anchor-alias value="101 (Switching Protocols)"/>
    26282635<t>
    2629    The server understands and is willing to comply with the client's request,
    2630    via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for
     2636   The <x:dfn>101 (Switching Protocols)</x:dfn> status code indicates that the
     2637   server understands and is willing to comply with the client's request,
     2638   via the <x:ref>Upgrade</x:ref> header field (&header-upgrade;), for
    26312639   a change in the application protocol being used on this connection. The
    2632    server will switch protocols to those defined by the response's Upgrade
    2633    header field immediately after the empty line which terminates the 101
    2634    response.
    2635 </t>
    2636 <t>
    2637    The protocol &SHOULD; be switched only when it is advantageous to do
    2638    so. For example, switching to a newer version of HTTP is advantageous
    2639    over older versions, and switching to a real-time, synchronous
    2640    protocol might be advantageous when delivering resources that use
    2641    such features.
     2640   server will switch to the protocol(s) indicated within the response's
     2641   Upgrade header field immediately after the empty line which terminates the
     2642   101 response.
     2643</t>
     2644<t>
     2645   It is assumed that the server will only agree to switch protocols when
     2646   it is advantageous to do so. For example, switching to a newer version of
     2647   HTTP might be advantageous over older versions, and switching to a
     2648   real-time, synchronous protocol might be advantageous when delivering
     2649   resources that use such features.
    26422650</t>
    26432651</section>
    … …  
    26582666  <x:anchor-alias value="200 (OK)"/>
    26592667<t>
    2660    The request has succeeded. The payload sent in the response
     2668   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
     2669   succeeded. The payload sent in the response
    26612670   is dependent on the method used in the request, for example:
    26622671  <list style="hanging">
    … …  
    26862695  <x:anchor-alias value="201 (Created)"/>
    26872696<t>
    2688    The request has been fulfilled and has resulted in one or more new resources
    2689    being created.
     2697   The <x:dfn>201 (Created)</x:dfn> status code indicates that the request has
     2698   been fulfilled and has resulted in one or more new resources being created.
    26902699</t>
    26912700<t>
    … …  
    26932702   with the most relevant URI also being carried in the <x:ref>Location</x:ref>
    26942703   header field. If the newly created resource's URI is the same as the
    2695    Effective Request URI, this information can be omitted (e.g., in the case of
    2696    a response to a PUT request). 
    2697 </t>
    2698 <t>
    2699    The origin server &MUST; create the resource(s) before sending the 201 status
    2700    code. If the action cannot be carried out immediately, the server &SHOULD;
    2701    respond with a <x:ref>202 (Accepted)</x:ref> response instead.
    2702 </t>
    2703 <t>
    2704    A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field
    2705    indicating the current value of the entity-tag for the representation of the
    2706    resource identified by the <x:ref>Location</x:ref> header field or, in case
    2707    the Location header field was omitted, by the Effective Request URI (see
    2708    &header-etag;).
     2704   effective request URI, the Location field can be omitted.
     2705</t>
     2706<t>
     2707   If an <x:ref>ETag</x:ref> header field is present in a 201 response, its
     2708   field value is the entity-tag for the representation created, which
     2709   is the new representation of the resource identified by either the
     2710   <x:ref>Location</x:ref> header field or, if no Location header field
     2711   is received, by the effective request URI (see &header-etag;).
    27092712</t>
    27102713</section>
    … …  
    27142717  <x:anchor-alias value="202 (Accepted)"/>
    27152718<t>
    2716    The request has been accepted for processing, but the processing has
    2717    not been completed.  The request might or might not eventually be
    2718    acted upon, as it might be disallowed when processing actually takes
    2719    place. There is no facility for re-sending a status code from an
    2720    asynchronous operation such as this.
     2719   The <x:dfn>202 (Accepted)</x:dfn> status code indicates that the request
     2720   has been accepted for processing, but the processing has not been
     2721   completed. The request might or might not eventually be acted upon, as it
     2722   might be disallowed when processing actually takes place. There is no
     2723   facility for re-sending a status code from an asynchronous operation such
     2724   as this.
    27212725</t>
    27222726<t>
    … …  
    27262730   requiring that the user agent's connection to the server persist
    27272731   until the process is completed. The representation sent with this
    2728    response &SHOULD; include an indication of the request's current status
     2732   response ought to describe the request's current status
    27292733   and either a pointer to a status monitor or some estimate of when the
    27302734   user can expect the request to be fulfilled.
    … …  
    27362740  <x:anchor-alias value="203 (Non-Authoritative Information)"/>
    27372741<t>
    2738    The request was successful but the enclosed payload has been modified
    2739    from that of the origin server's <x:ref>200 (OK)</x:ref> response by a
    2740    transforming proxy (&transformations;). This status code allows the proxy
    2741    to notify recipients when a transformation has been applied, since that
    2742    knowledge might impact later decisions regarding the content.
    2743    For example, future cache validation requests for the content might only
    2744    be applicable along the same request path (through the same proxies).
     2742   The <x:dfn>203 (Non-Authoritative Information)</x:dfn> status code
     2743   indicates that the request was successful but the enclosed payload has been
     2744   modified from that of the origin server's <x:ref>200 (OK)</x:ref> response
     2745   by a transforming proxy (&transformations;). This status code allows the
     2746   proxy to notify recipients when a transformation has been applied, since
     2747   that knowledge might impact later decisions regarding the content. For
     2748   example, future cache validation requests for the content might only be
     2749   applicable along the same request path (through the same proxies).
    27452750</t>
    27462751<t>
    … …  
    27552760  <x:anchor-alias value="204 (No Content)"/>
    27562761<t>
    2757    The 204 (No Content) status code indicates that the server has
    2758    successfully fulfilled the request and that there is no additional
    2759    content to send in the response payload body.  Metadata in the
    2760    response header fields refer to the target resource and its current
    2761    representation after the requested action.
     2762   The <x:dfn>204 (No Content)</x:dfn> status code indicates that the server
     2763   has successfully fulfilled the request and that there is no additional
     2764   content to send in the response payload body. Metadata in the response
     2765   header fields refer to the target resource and its current representation
     2766   after the requested action.
    27622767</t>
    27632768<t>
    … …  
    27692774<t>
    27702775   The 204 response allows a server to indicate that the action has been
    2771    successfully applied to the target resource while implying that the
    2772    user agent &SHOULD-NOT; traverse away from its current "document view"
     2776   successfully applied to the target resource, while implying that the
     2777   user agent does not need to traverse away from its current "document view"
    27732778   (if any).  The server assumes that the user agent will provide some
    27742779   indication of the success to its user, in accord with its own interface,
    … …  
    27842789</t>
    27852790<t>
    2786    The 204 response &MUST-NOT; include a message body, and thus is always
     2791   A 204 response does not include a message body, and thus is always
    27872792   terminated by the first empty line after the header fields.
    27882793</t>
    … …  
    27922797  <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/>
    27932798<t>
    2794    The server has fulfilled the request and the user agent &SHOULD; reset
    2795    the document view which caused the request to be sent. This response
    2796    is primarily intended to allow input for actions to take place via
    2797    user input, followed by a clearing of the form in which the input is
    2798    given so that the user can easily initiate another input action.
     2799   The <x:dfn>205 (Reset Content)</x:dfn> status code indicates that the
     2800   server has fulfilled the request and desires that the user agent reset the
     2801   "document view", which caused the request to be sent, to its original state
     2802   as received from the origin server.
    27992803</t>
    28002804<t>   
    2801    The message body included with the response &MUST; be empty. Note that
    2802    receivers still need to parse the response according to the algorithm defined
    2803    in &message-body;.
     2805   This response is intended to support a common data entry use case where
     2806   the user receives content that supports data entry (a form, notepad,
     2807   canvas, etc.), enters or manipulates data in that space, causes the entered
     2808   data to be submitted in a request, and then the data entry mechanism is
     2809   reset for the next entry so that the user can easily initiate another
     2810   input action.
     2811</t>
     2812<t>
     2813   Since the 205 status code implies that no additional content will be
     2814   provided in the payload, the server &MUST; send a message body of zero
     2815   length. In other words, the server &MUST; send a "Content-Length: 0" field
     2816   in a 205 response or close the connection immediately after sending the
     2817   blank line terminating the header section.
    28042818</t>
    28052819</section>
Note: See TracChangeset for help on using the changeset viewer.