Changeset 2057 for draft-ietf-httpbis


Ignore:
Timestamp:
27/12/12 15:58:30 (10 years ago)
Author:
fielding@…
Message:

editorial improvements to 4xx status codes; partly addresses #419

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2056 r2057  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 23, 2013";
     451       content: "Expires June 30, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2012-12-20">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12-27">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">December 20, 2012</td>
     525               <td class="right">December 27, 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: June 23, 2013</td>
     528               <td class="left">Expires: June 30, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on June 23, 2013.</p>
     556      <p>This Internet-Draft will expire on June 30, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    699699                     <li><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;&nbsp;&nbsp;<a href="#status.410">410 Gone</a></li>
    700700                     <li><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;&nbsp;&nbsp;<a href="#status.411">411 Length Required</a></li>
    701                      <li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Request Representation Too Large</a></li>
     701                     <li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Request Payload Too Large</a></li>
    702702                     <li><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li>
    703703                     <li><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li>
    … …  
    10791079         <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    10801080         </li>
    1081          <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the target resource; as such, the effective request URI might only
    1082             act as an identifier for the payload's representation when a request is made via the same chain of intermediaries.
     1081         <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the <a href="#resources" class="smpl">target resource</a>; as such, the effective request URI might only act as an identifier for the payload's representation when a request is made
     1082            via the same chain of intermediaries.
    10831083         </li>
    10841084         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
    … …  
    11521152         by both the request method and the response status code.
    11531153      </p>
    1154       <p id="rfc.section.3.3.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in
    1155          the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
     1154      <p id="rfc.section.3.3.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
    11561155         an HTML form.
    11571156      </p>
    1158       <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
     1157      <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
    11591158         current representation of the target resource after applying the processing. Response messages with an error status code usually
    11601159         contain a representation that describes the error and what next steps are suggested for resolving it.
    … …  
    12061205      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
    12071206      <p id="rfc.section.3.4.1.p.1">When content negotiation preferences are sent by the user agent in a request in order to encourage an algorithm located at
    1208          the server to select the preferred representation, it is called <dfn>proactive negotiation</dfn> (a.k.a., <dfn>server-driven negotiation</dfn>). Selection is based on the available representations for a response (the dimensions over which it might vary; e.g., language,
     1207         the server to select the preferred representation, it is called <dfn>proactive negotiation</dfn> (a.k.a., <dfn>server-driven negotiation</dfn>). Selection is based on the available representations for a response (the dimensions over which it might vary, such as language,
    12091208         content-coding, etc.) compared to various information supplied in the request, including both the explicit negotiation fields
    12101209         of <a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a> and implicit characteristics, such as the client's network address or parts of the <a href="#header.user-agent" class="smpl">User-Agent</a> field.
    … …  
    12621261      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a>
    12631262</pre><p id="rfc.section.4.1.p.3">HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned
    1264          as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would
    1265          apply semantics. The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive
    1266          method names.
     1263         as applying semantics to a <a href="#resources" class="smpl">target resource</a> in much the same way as invoking a defined method on an identified object would apply semantics. The method token is case-sensitive
     1264         because it might be used as a gateway to object-based systems with case-sensitive method names.
    12671265      </p>
    12681266      <p id="rfc.section.4.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide
    … …  
    13901388      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
    13911389      <div id="rfc.iref.g.16"></div>
    1392       <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the target resource.</p>
     1390      <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the <a href="#resources" class="smpl">target resource</a>.
     1391      </p>
    13931392      <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, the produced data will be sent as the representation, not the source text
    13941393         of the process, unless that text happens to be the output of the process.
    … …  
    14221421      <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
    14231422      <p id="rfc.section.4.3.3.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
    1424          by the target resource. For example, POST is frequently used for the following functions (among others):
     1423         by the <a href="#resources" class="smpl">target resource</a>. For example, POST is frequently used for the following functions (among others):
    14251424      </p>
    14261425      <ul>
    … …  
    14441443      <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h3>
    14451444      <div id="rfc.iref.p.3"></div>
    1446       <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
    1447          enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
    1448          that same target resource will result in an equivalent representation being sent in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
     1445      <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the <a href="#resources" class="smpl">target resource</a> be created or replaced with the state defined by the representation enclosed in the request message payload. A successful
     1446         PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent
     1447         representation being sent in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
    14491448         upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent
    14501449         GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing
    … …  
    15071506      <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
    15081507      <div id="rfc.iref.d.2"></div>
    1509       <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the target resource and its current representations
    1510          or implementation. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI
    1511          mapping of the origin server, rather than an expectation that the information be deleted. The representations might or might
    1512          not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the
    1513          nature of the resource and its implementation by the origin server (which are beyond the scope of this specification).
     1508      <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the <a href="#resources" class="smpl">target resource</a> and its current representations or implementation. In effect, this method is similar to the rm command in UNIX: it expresses
     1509         a deletion operation on the URI mapping of the origin server, rather than an expectation that the information be deleted.
     1510         The representations might or might not be destroyed by the origin server, and the associated storage might or might not be
     1511         reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond
     1512         the scope of this specification).
    15141513      </p>
    15151514      <p id="rfc.section.4.3.5.p.2">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has
    … …  
    17211720      </ul>
    17221721      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="request.conditionals" href="#request.conditionals">Conditionals</a></h2>
    1723       <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the
    1724          target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target
    1725          resource is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
     1722      <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the <a href="#resources" class="smpl">target resource</a>. Each precondition is based on metadata that is expected to change if the selected representation of the target resource
     1723         is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    17261724      </p>
    17271725      <div id="rfc.table.u.4">
    … …  
    22922290                  <td class="left">413</td>
    22932291                  <td class="left">Request Representation Too Large</td>
    2294                   <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section&nbsp;6.5.11</a></td>
     2292                  <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Payload Too Large">Section&nbsp;6.5.11</a></td>
    22952293               </tr>
    22962294               <tr>
    … …  
    23962394      <dl>
    23972395         <dt>GET</dt>
    2398          <dd>a representation of the target resource is sent in the response;</dd>
     2396         <dd>a representation of the <a href="#resources" class="smpl">target resource</a>;
     2397         </dd>
    23992398         <dt>HEAD</dt>
    24002399         <dd>the same representation as GET, except without the message body;</dd>
    … …  
    24382437      <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>
    24392438      <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.
     2439         in the response payload body. Metadata in the response header fields refer to the <a href="#resources" class="smpl">target resource</a> and its current representation after the requested action.
    24422440      </p>
    24432441      <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
    … …  
    25132511      <div id="rfc.iref.73"></div>
    25142512      <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    2515       <p id="rfc.section.6.4.1.p.1">The <dfn>300 (Multiple Choices)</dfn> status code indicates that the target resource has more than one representation, each with its own more specific identifier,
    2516          and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation
    2517          by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage
    2518          in reactive negotiation to select the most appropriate representation(s) for its needs (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).
     2513      <p id="rfc.section.6.4.1.p.1">The <dfn>300 (Multiple Choices)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has more than one representation, each with its own more specific identifier, and information about the alternatives is being
     2514         provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more
     2515         of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the
     2516         most appropriate representation(s) for its needs (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).
    25192517      </p>
    25202518      <p id="rfc.section.6.4.1.p.2">For request methods other than HEAD, the server <em class="bcp14">SHOULD</em> generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user
    … …  
    25282526      <div id="rfc.iref.73"></div>
    25292527      <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
    2530       <p id="rfc.section.6.4.2.p.1">The <dfn>301 (Moved Permanently)</dfn> status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource
    2531          ought to use one of the enclosed URIs. Clients with link editing capabilities ought to automatically re-link references to
    2532          the effective request URI to one or more of the new references sent by the server, where possible.
     2528      <p id="rfc.section.6.4.2.p.1">The <dfn>301 (Moved Permanently)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients
     2529         with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the
     2530         new references sent by the server, where possible.
    25332531      </p>
    25342532      <p id="rfc.section.6.4.2.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a preferred URI reference for the new permanent URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note
    … …  
    25642562         can be separately identified, bookmarked, and cached independent of the original request.
    25652563      </p>
    2566       <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    2567          transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful
     2564      <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the <a href="#resources" class="smpl">target resource</a> resource does not have a representation of its own that can be transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI identifies a resource that is descriptive of the target resource, such that the follow-on representation might be useful
    25682565         to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what
    25692566         can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP
    … …  
    25822579      <div id="rfc.iref.73"></div>
    25832580      <h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
    2584       <p id="rfc.section.6.4.7.p.1">The <dfn>307 (Temporary Redirect)</dfn> status code indicates that the target resource resides temporarily under a different URI and the user agent <em class="bcp14">MUST NOT</em> change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time,
     2581      <p id="rfc.section.6.4.7.p.1">The <dfn>307 (Temporary Redirect)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> resides temporarily under a different URI and the user agent <em class="bcp14">MUST NOT</em> change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time,
    25852582         the client ought to continue using the original effective request URI for future requests.
    25862583      </p>
    … …  
    26022599      <div id="rfc.iref.74"></div>
    26032600      <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a id="status.400" href="#status.400">400 Bad Request</a></h3>
    2604       <p id="rfc.section.6.5.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p>
     2601      <p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical,
     2602         or exceeds some limitation on what the server is willing to process.
     2603      </p>
    26052604      <div id="rfc.iref.74"></div>
    26062605      <h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;<a id="status.402" href="#status.402">402 Payment Required</a></h3>
    … …  
    26092608      <div id="rfc.iref.74"></div>
    26102609      <h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h3>
    2611       <p id="rfc.section.6.5.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might
    2612          be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials.
    2613       </p>
    2614       <p id="rfc.section.6.5.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available
    2615          to the client, the status code <a href="#status.404" class="smpl">404
    2616             (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
     2610      <p id="rfc.section.6.5.3.p.1">The <dfn>403 (Forbidden)</dfn> status code indicates that the origin server understood the request but refuses to authorize it. A server that wishes to make
     2611         public why the request has been forbidden can describe that reason in the response payload (if any).
     2612      </p>
     2613      <p id="rfc.section.6.5.3.p.2">If authentication credentials were provided in the request, the origin server considers them insufficient to grant access.
     2614         The client <em class="bcp14">SHOULD NOT</em> repeat the request with the same credentials. The client <em class="bcp14">MAY</em> repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
     2615      </p>
     2616      <p id="rfc.section.6.5.3.p.3">An origin server that wishes to "hide" the current existence of a forbidden <a href="#resources" class="smpl">target resource</a>  <em class="bcp14">MAY</em> instead respond with a status code of <a href="#status.404" class="smpl">404 (Not Found)</a>.
    26172617      </p>
    26182618      <div id="rfc.iref.74"></div>
    26192619      <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    2620       <p id="rfc.section.6.5.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
    2621          or permanent. The <a href="#status.410" class="smpl">410 (Gone)</a> status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
    2622          and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
    2623          has been refused, or when no other response is applicable.
     2620      <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status does not indicate whether this lack of representation is temporary
     2621         or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition
     2622         is likely to be permanent.
    26242623      </p>
    26252624      <div id="rfc.iref.74"></div>
    26262625      <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    2627       <p id="rfc.section.6.5.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource.
     2626      <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is not allowed by the origin server for the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in the response containing a list of valid methods for the requested resource.
    26282627      </p>
    26292628      <div id="rfc.iref.74"></div>
    26302629      <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    2631       <p id="rfc.section.6.5.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    2632          not acceptable according to the <a href="#header.accept" class="smpl">Accept</a> and Accept-* header fields sent in the request.
    2633       </p>
    2634       <p id="rfc.section.6.5.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
    2635          or user agent can choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection
    2636          of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    2637       </p>
    2638       <div class="note" id="rfc.section.6.5.6.p.3">
    2639          <p> <b>Note:</b> HTTP/1.1 servers are allowed to send responses which are not acceptable according to the accept header fields sent in the
    2640             request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the
    2641             header fields of an incoming response to determine if it is acceptable.
    2642          </p>
    2643       </div>
    2644       <p id="rfc.section.6.5.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions.
     2630      <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation which would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.
     2631      </p>
     2632      <p id="rfc.section.6.5.6.p.2">The server <em class="bcp14">SHOULD</em> generate a payload containing a list of available representation characteristics and corresponding resource identifiers from
     2633         which the user or user agent can choose the one most appropriate. A user agent <em class="bcp14">MAY</em> automatically select the most appropriate choice from that list. However, this specification does not define any standard
     2634         for such automatic selection. [The original proposal for 406 defined the Alternates header field as providing a list of alternative
     2635         representations, such that it would be available for responses to the HEAD method, but lack of deployment led to Alternates
     2636         being dropped from the specification.]
    26452637      </p>
    26462638      <div id="rfc.iref.74"></div>
    26472639      <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h3>
    2648       <p id="rfc.section.6.5.7.p.1">The server did not receive a complete request message within the time that it was prepared to wait. If the client has sent
    2649          a request, it <em class="bcp14">MAY</em> repeat that request, possibly on a new connection if the server indicates that the present connection is being closed.
     2640      <p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.
     2641         Since the only reason to send this message is if the server has decided to close the connection, the server <em class="bcp14">SHOULD</em> indicate that intent with the <a href="p1-messaging.html#header.connection" class="smpl">close</a> connection option (<a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</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>). If the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection.
    26502642      </p>
    26512643      <div id="rfc.iref.74"></div>
    26522644      <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
    2653       <p id="rfc.section.6.5.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
    2654          situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The payload <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
    2655          include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
     2645      <p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the resource. This
     2646         code is only reasonable in situations where it is expected that the user might be able to resolve the conflict and resubmit
     2647         the request. The server <em class="bcp14">SHOULD</em> generate a payload that includes enough information for the user to recognize the source of the conflict. Ideally, the response
     2648         would include enough information for the user or user agent to fix the problem; however, that might not be possible and is
     2649         not required.
    26562650      </p>
    26572651      <p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation
    … …  
    26622656      <div id="rfc.iref.74"></div>
    26632657      <h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
    2664       <p id="rfc.section.6.5.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
    2665          be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine,
    2666          whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a>  <em class="bcp14">SHOULD</em> be used instead.
     2658      <p id="rfc.section.6.5.9.p.1">The <dfn>410 (Gone)</dfn> status code indicates that access to the <a href="#resources" class="smpl">target resource</a> is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not
     2659         know, or has no facility to determine, whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a> ought to be used instead.
    26672660      </p>
    26682661      <p id="rfc.section.6.5.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource
    26692662         is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event
    2670          is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's
    2671          site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time
    2672          — that is left to the discretion of the server owner.
     2663         is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the
     2664         origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for
     2665         any length of time — that is left to the discretion of the server owner.
    26732666      </p>
    26742667      <p id="rfc.section.6.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
    … …  
    26762669      <div id="rfc.iref.74"></div>
    26772670      <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
    2678       <p id="rfc.section.6.5.10.p.1">The server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
     2671      <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</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>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
    26792672         message.
    26802673      </p>
    26812674      <div id="rfc.iref.74"></div>
    2682       <h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3>
    2683       <p id="rfc.section.6.5.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able
    2684          to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
    2685       </p>
    2686       <p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
     2675      <h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a id="status.413" href="#status.413">413 Request Payload Too Large</a></h3>
     2676      <p id="rfc.section.6.5.11.p.1">The <dfn>413 (Request Payload Too Large)</dfn> status code indicates that the server is refusing to process a request because the request payload is larger than the server
     2677         is willing or able to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
     2678      </p>
     2679      <p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
    26872680      </p>
    26882681      <div id="rfc.iref.74"></div>
    26892682      <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
    2690       <p id="rfc.section.6.5.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
    2691          This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
    2692          query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
    2693          points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
    2694          in some servers using fixed-length buffers for reading or manipulating the request-target.
     2683      <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</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>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly
     2684         converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of
     2685         redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client
     2686         attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the request-target.
    26952687      </p>
    26962688      <div id="rfc.iref.74"></div>
    26972689      <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    2698       <p id="rfc.section.6.5.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
    2699          on the target resource. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
     2690      <p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported
     2691         by the <a href="#resources" class="smpl">target resource</a> for this method. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
    27002692      </p>
    27012693      <div id="rfc.iref.74"></div>
    27022694      <h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    2703       <p id="rfc.section.6.5.14.p.1">The expectation given in an <a href="#header.expect" class="smpl">Expect</a> header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    2704          not be met by the next-hop server.
     2695      <p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.2</a>) could not be met by at least one of the inbound servers.
    27052696      </p>
    27062697      <div id="rfc.iref.74"></div>
    27072698      <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>
    2708       <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.
     2699      <p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do
     2700         so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</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>).
    27092701      </p>
    27102702      <div id="rfc.figure.u.41"></div>
    … …  
    27162708
    27172709<span id="s426body">This service requires use of the HTTP/3.0 protocol.
    2718 </span></pre><p id="rfc.section.6.5.15.p.3">The server <em class="bcp14">SHOULD</em> include a message body in the 426 response which indicates in human readable form the reason for the error and describes any
    2719          alternative courses which might be available to the user.
    2720       </p>
    2721       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
     2710</span></pre><h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
    27222711      <div id="rfc.iref.74"></div>
    27232712      <div id="rfc.iref.s.6"></div>
    2724       <p id="rfc.section.6.6.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
    2725          of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
     2713      <p id="rfc.section.6.6.p.1">The <dfn>5xx (Server Error)</dfn> class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.
     2714         Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
    27262715         User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
    27272716      </p>
    … …  
    27652754      <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
    27662755         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2767          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.
     2756         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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.
    27682757      </p>
    27692758      <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>
    27702759      <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
    2771          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>).
     2760         status-line. These header fields give information about the server and about further access to the <a href="#resources" class="smpl">target resource</a>.
    27722761      </p>
    27732762      <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>
    … …  
    29632952</pre><p id="rfc.section.7.1.3.p.8">In the latter example, the delay is 2 minutes.</p>
    29642953      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
    2965       <p id="rfc.section.7.2.p.1"><span id="rfc.iref.s.7"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if
    2966          the same request had used the method GET and excluded any conditional request header fields.
     2954      <p id="rfc.section.7.2.p.1"><span id="rfc.iref.s.7"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of the <a href="#resources" class="smpl">target resource</a> that would have been selected in a successful response if the same request had used the method GET and excluded any conditional
     2955         request header fields.
    29672956      </p>
    29682957      <p id="rfc.section.7.2.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
    … …  
    30413030      </div>
    30423031      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="response.context" href="#response.context">Response Context</a></h2>
    3043       <p id="rfc.section.7.4.p.1">The remaining response header fields provide more information about the target resource for potential use in later requests.</p>
     3032      <p id="rfc.section.7.4.p.1">The remaining response header fields provide more information about the <a href="#resources" class="smpl">target resource</a> for potential use in later requests.
     3033      </p>
    30443034      <div id="rfc.table.u.13">
    30453035         <table class="tt full left" cellpadding="3" cellspacing="0">
    … …  
    30683058      <div id="rfc.iref.a.5"></div>
    30693059      <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h3>
    3070       <p id="rfc.section.7.4.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
    3071          is strictly to inform the recipient of valid request methods associated with the resource.
     3060      <p id="rfc.section.7.4.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the <a href="#resources" class="smpl">target resource</a>. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.
    30723061      </p>
    30733062      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.60"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method.overview" class="smpl">method</a>
    … …  
    30853074      </p>
    30863075      <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> ) )
    3087 </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
     3076</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.29"><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
    30883077         are listed in order of their significance for identifying the origin server software. Each product identifier consists of
    30893078         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>.
    … …  
    31183107         to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    31193108      </p>
    3120       <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
     3109      <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.30"><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
    31213110         parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of
    31223111         new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a
    … …  
    33873376               <tr>
    33883377                  <td class="left">413</td>
    3389                   <td class="left">Request Representation Too Large</td>
    3390                   <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Representation Too Large">Section&nbsp;6.5.11</a>
     3378                  <td class="left">Request Payload Too Large</td>
     3379                  <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Payload Too Large">Section&nbsp;6.5.11</a>
    33913380                  </td>
    33923381               </tr>
    … …  
    34593448      <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>
    34603449      <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,
    3461          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.
     3450         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.31"><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.
    34623451      </p>
    34633452      <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
    … …  
    34663455         processing, since the prefix would ensure that private names never collide with a newly registered Internet name.)
    34673456      </p>
    3468       <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
     3457      <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.32"><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
    34693458         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>.
    34703459      </p>
    34713460      <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
    34723461         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    3473          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>).
     3462         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.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    34743463      </p>
    34753464      <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
    … …  
    34893478      <ul>
    34903479         <li>
    3491             <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>).
     3480            <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.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    34923481            </p>
    34933482            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    35053494         </li>
    35063495         <li>
    3507             <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>).
     3496            <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.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    35083497            </p>
    35093498         </li>
    … …  
    35163505         </li>
    35173506         <li>
    3518             <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>).
     3507            <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.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    35193508            </p>
    35203509         </li>
    … …  
    36823671      <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>
    36833672      <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>
    3684       <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;.
     3673      <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.37"><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;.
    36853674      </p>
    36863675      <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>
    … …  
    36923681         <li>Pointer to specification text</li>
    36933682      </ul>
    3694       <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>).
     3683      <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.38"><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.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    36953684      </p>
    36963685      <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.
    … …  
    37123701                  <td class="left">compress</td>
    37133702                  <td class="left">UNIX "compress" program method</td>
    3714                   <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>
     3703                  <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.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    37153704                  </td>
    37163705               </tr>
    … …  
    37193708                  <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>)
    37203709                  </td>
    3721                   <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>
     3710                  <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.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    37223711                  </td>
    37233712               </tr>
    … …  
    37253714                  <td class="left">gzip</td>
    37263715                  <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>
    3727                   <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>
     3716                  <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.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    37283717                  </td>
    37293718               </tr>
    … …  
    38173806      </p>
    38183807      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    3819       <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>.
     3808      <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.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    38203809      </p>
    38213810      <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References
    … …  
    41554144         trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;7.4.1</a>)
    41564145      </p>
    4157       <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>)
     4146      <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.44"><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>)
    41584147      </p>
    41594148      <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>)
    … …  
    41804169         (any visible US-ASCII character).
    41814170      </p>
    4182       <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>:
    4183       </p>
    4184       <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;
    4185   <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;
    4186   <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;
    4187   <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;
    4188   <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;
    4189   <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;
    4190   <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;
    4191   <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;
    4192   <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;
    4193   <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;
    4194   <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;
     4171      <p id="rfc.section.D.p.2">The rules below are 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>:
     4172      </p>
     4173      <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.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;
     4174  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, 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;
     4175  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, 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#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4176  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, 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;
     4177  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4178  <a href="#imported.abnf" class="smpl">comment</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#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4179  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, 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#header.fields" title="Header Fields">Section 3.2</a>&gt;
     4180  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4181  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, 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;
     4182  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, 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;
     4183  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><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;
    41954184</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>
    41964185      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    … …  
    43904379                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">8.2.3</a></li>
    43914380                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">8.2.3</a></li>
    4392                   <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li>
     4381                  <li>413 Request Payload Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li>
    43934382                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">8.2.3</a></li>
    43944383                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.74"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li>
    … …  
    45444533            </li>
    45454534            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4546                   <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>
     4535                  <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.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</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.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</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">8.4.2</a>, <a href="#rfc.xref.Part1.43">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.44">C</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>, <a href="#rfc.xref.Part1.56">D</a><ul>
    45474536                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    45484537                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    4549                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">6.6.6</a></li>
    4550                         <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>
    4551                         <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>
    4552                         <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>
    4553                         <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>
     4538                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.6.6</a></li>
     4539                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>
     4540                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.52">D</a></li>
     4541                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>
     4542                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>
    45544543                        <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>
    4555                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">8.1.2</a></li>
    4556                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">3.3</a></li>
    4557                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">8.4.1</a></li>
    4558                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">8.3.1</a></li>
    4559                         <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>
    4560                         <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>
    4561                         <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>
    4562                         <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>
     4544                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.1.2</a></li>
     4545                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.25">6.5.10</a></li>
     4546                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.38">8.4.1</a></li>
     4547                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">8.3.1</a></li>
     4548                        <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.40">8.4.2</a></li>
     4549                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.39">8.4.1</a></li>
     4550                        <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.41">8.4.2</a></li>
     4551                        <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.42">8.4.2</a></li>
    45634552                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.5</a></li>
    4564                         <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>
     4553                        <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>, <a href="#rfc.xref.Part1.26">6.5.12</a></li>
    45654554                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
    4566                         <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>
    4567                         <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>
     4555                        <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></li>
     4556                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li>
    45684557                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.3.4</a></li>
    4569                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a></li>
    4570                         <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>
     4558                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li>
     4559                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.27">6.5.15</a></li>
    45714560                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a></li>
    4572                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">10</a></li>
    4573                         <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.3.1</a></li>
     4561                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">10</a></li>
     4562                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">8.3.1</a></li>
    45744563                     </ul>
    45754564                  </li>
    … …  
    47254714            </li>
    47264715            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    4727                   <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.xref.TRACE.4">9.1</a>, <a href="#rfc.extref.t.23">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>
     4716                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.xref.TRACE.4">9.1</a>, <a href="#rfc.extref.t.48">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>
    47284717               </ul>
    47294718            </li>

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

    r2056 r2057  
    718718      <t>If the request is GET or HEAD and the response status code is
    719719         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is a
    720          potentially modified representation of the target resource; as such,
    721          the effective request URI might only act as an identifier for the
    722          payload's representation when a request is made via the same chain
    723          of intermediaries.</t>
     720         potentially modified representation of the
     721         <x:ref>target resource</x:ref>; as such, the effective request URI
     722         might only act as an identifier for the payload's representation when
     723         a request is made via the same chain of intermediaries.</t>
    724724      <t>If the response has a <x:ref>Content-Location</x:ref> header field
    725725         and its field-value is a reference to the same URI as the effective
    … …  
    864864<t>
    865865   For example, a representation in the payload of a PUT request
    866    (<xref target="PUT"/>) represents the desired state of the target resource
     866   (<xref target="PUT"/>) represents the desired state of the <x:ref>target resource</x:ref>
    867867   if the request is successfully applied, whereas a representation in the
    868868   payload of a POST request (<xref target="POST"/>) represents an anonymous
    … …  
    872872<t>
    873873   Likewise, the payload of a <x:ref>200 (OK)</x:ref> response to GET
    874    (<xref target="GET"/>) contains a representation of the target resource,
     874   (<xref target="GET"/>) contains a representation of the <x:ref>target resource</x:ref>,
    875875   as observed at the time of the message origination date
    876876   (<xref target="header.date"/>), whereas the same status code in a response
    … …  
    940940   (a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on
    941941   the available representations for a response (the dimensions over which it
    942    might vary; e.g., language, content-coding, etc.) compared to various
     942   might vary, such as language, content-coding, etc.) compared to various
    943943   information supplied in the request, including both the explicit
    944944   negotiation fields of <xref target="request.conneg"/> and implicit
    … …  
    10561056   HTTP was originally designed to be usable as an interface to distributed
    10571057   object systems.  The request method was envisioned as applying
    1058    semantics to a target resource in much the same way as invoking a defined
     1058   semantics to a <x:ref>target resource</x:ref> in much the same way as invoking a defined
    10591059   method on an identified object would apply semantics. The method token
    10601060   is case-sensitive because it might be used as a gateway to object-based
    … …  
    12391239<t>
    12401240   The GET method requests transfer of a current representation of
    1241    the target resource.
     1241   the <x:ref>target resource</x:ref>.
    12421242</t>
    12431243<t>   
    … …  
    13131313   The POST method requests that the origin server accept the
    13141314   representation enclosed in the request as data to be processed by the
    1315    target resource. For example, POST is frequently used for the following
     1315   <x:ref>target resource</x:ref>. For example, POST is frequently used for the following
    13161316   functions (among others):
    13171317  <list style="symbols">
    … …  
    13701370  <iref primary="true" item="PUT method" x:for-anchor=""/>
    13711371<t>
    1372    The PUT method requests that the state of the target resource
     1372   The PUT method requests that the state of the <x:ref>target resource</x:ref>
    13731373   be created or replaced with the state defined by the representation
    13741374   enclosed in the request message payload.  A successful PUT of a given
    … …  
    14981498<t>
    14991499   The DELETE method requests that the origin server remove the association
    1500    between the target resource and its current representations or
     1500   between the <x:ref>target resource</x:ref> and its current representations or
    15011501   implementation. In effect, this method is similar to the rm command in
    15021502   UNIX: it expresses a deletion operation on the URI mapping of the
    … …  
    19361936<t>
    19371937   Conditionals are request header fields that indicate a precondition to be
    1938    tested before applying the method semantics to the target resource.
     1938   tested before applying the method semantics to the <x:ref>target resource</x:ref>.
    19391939   Each precondition is based on metadata that is expected to change if the
    19401940   selected representation of the target resource is changed.  The HTTP/1.1
    … …  
    26712671  <list style="hanging">
    26722672    <t hangText="GET">
    2673       a representation of the target resource is sent in the response;
     2673      a representation of the <x:ref>target resource</x:ref>;
    26742674    </t>
    26752675    <t hangText="HEAD">
    … …  
    27632763   has successfully fulfilled the request and that there is no additional
    27642764   content to send in the response payload body. Metadata in the response
    2765    header fields refer to the target resource and its current representation
     2765   header fields refer to the <x:ref>target resource</x:ref> and its current representation
    27662766   after the requested action.
    27672767</t>
    … …  
    29112911<t>
    29122912   The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the
    2913    target resource has more than one representation, each with its own more
     2913   <x:ref>target resource</x:ref> has more than one representation, each with its own more
    29142914   specific identifier, and information about the alternatives is being
    29152915   provided so that the user (or user agent) can select a preferred
    … …  
    29462946<t>
    29472947   The <x:dfn>301 (Moved Permanently)</x:dfn> status code indicates that the
    2948    target resource has been assigned a new permanent URI and any future
    2949    references to this resource ought to use one of the enclosed URIs. Clients
    2950    with link editing capabilities ought to automatically re-link references to
    2951    the effective request URI to one or more of the new references sent by the
    2952    server, where possible.
     2948   <x:ref>target resource</x:ref> has been assigned a new permanent URI and
     2949   any future references to this resource ought to use one of the enclosed
     2950   URIs. Clients with link editing capabilities ought to automatically re-link
     2951   references to the effective request URI to one or more of the new
     2952   references sent by the server, where possible.
    29532953</t>
    29542954<t>
    … …  
    30233023</t>
    30243024<t>
    3025    A 303 response to a GET request indicates that the requested
    3026    resource does not have a representation of its own that can be
    3027    transferred by the server over HTTP.  The <x:ref>Location</x:ref> URI
    3028    indicates a resource that is descriptive of the target resource, such that
    3029    the follow-on representation might be useful to recipients without
    3030    implying that it adequately represents the target resource.
    3031    Note that answers to the questions of what can be represented, what
    3032    representations are adequate, and what might be a useful description
    3033    are outside the scope of HTTP and thus entirely determined by the
    3034    URI owner(s).
     3025   A 303 response to a GET request indicates that the
     3026   <x:ref>target resource</x:ref> resource does not have a representation of
     3027   its own that can be transferred by the server over HTTP.
     3028   The <x:ref>Location</x:ref> URI identifies a resource that is descriptive
     3029   of the target resource, such that the follow-on representation might be
     3030   useful to recipients without implying that it adequately represents the
     3031   target resource. Note that answers to the questions of what can be
     3032   represented, what representations are adequate, and what might be a useful
     3033   description are outside the scope of HTTP and thus entirely determined by
     3034   the URI owner(s).
    30353035</t>
    30363036<t>
    … …  
    30653065<t>
    30663066   The <x:dfn>307 (Temporary Redirect)</x:dfn> status code indicates that the
    3067    target resource resides temporarily under a different URI and the
    3068    user agent &MUST-NOT; change the request method if it performs an automatic
    3069    redirection to that URI.
     3067   <x:ref>target resource</x:ref> resides temporarily under a different URI
     3068   and the user agent &MUST-NOT; change the request method if it performs an
     3069   automatic redirection to that URI.
    30703070   Since the redirection can change over time, the client ought to continue
    30713071   using the original effective request URI for future requests.
    … …  
    31083108  <x:anchor-alias value="400 (Bad Request)"/>
    31093109<t>
    3110    The server cannot or will not process the request, due to a client error (e.g.,
    3111    malformed syntax).
     3110   The <x:dfn>400 (Bad Request)</x:dfn> status code indicates that the server
     3111   cannot or will not process the request because the received syntax is
     3112   invalid, nonsensical, or exceeds some limitation on what the server is
     3113   willing to process.
    31123114</t>
    31133115</section>
    … …  
    31263128  <x:anchor-alias value="403 (Forbidden)"/>
    31273129<t>
    3128    The server understood the request, but refuses to authorize it. Providing
    3129    different user authentication credentials might be successful, but any
    3130    credentials that were provided in the request are insufficient. The request
    3131    &SHOULD-NOT; be repeated with the same credentials.
    3132 </t>
    3133 <t>
    3134    If the request method was not HEAD and the server wishes to make
    3135    public why the request has not been fulfilled, it &SHOULD; describe the
    3136    reason for the refusal in the representation.  If the server does not wish to
    3137    make this information available to the client, the status code <x:ref>404
    3138    (Not Found)</x:ref> &MAY; be used instead.
     3130   The <x:dfn>403 (Forbidden)</x:dfn> status code indicates that the origin
     3131   server understood the request but refuses to authorize it.
     3132   A server that wishes to make public why the request has been forbidden
     3133   can describe that reason in the response payload (if any).
     3134</t>
     3135<t>
     3136   If authentication credentials were provided in the request, the origin
     3137   server considers them insufficient to grant access.
     3138   The client &SHOULD-NOT; repeat the request with the same credentials.
     3139   The client &MAY; repeat the request with new or different credentials.
     3140   However, a request might be forbidden for reasons unrelated to the
     3141   credentials.
     3142</t>
     3143<t>
     3144   An origin server that wishes to "hide" the current existence of a forbidden
     3145   <x:ref>target resource</x:ref> &MAY; instead respond with a status
     3146   code of <x:ref>404 (Not Found)</x:ref>.
    31393147</t>
    31403148</section>
    … …  
    31443152  <x:anchor-alias value="404 (Not Found)"/>
    31453153<t>
    3146    The server has not found anything matching the effective request URI. No
    3147    indication is given of whether the condition is temporary or
    3148    permanent. The <x:ref>410 (Gone)</x:ref> status code &SHOULD; be used if the server
    3149    knows, through some internally configurable mechanism, that an old
    3150    resource is permanently unavailable and has no forwarding address.
    3151    This status code is commonly used when the server does not wish to
    3152    reveal exactly why the request has been refused, or when no other
    3153    response is applicable.
     3154   The <x:dfn>404 (Not Found)</x:dfn> status code indicates that the origin
     3155   server did not find a current representation for the
     3156   <x:ref>target resource</x:ref> or is not willing to disclose that one
     3157   exists. A 404 status does not indicate whether this lack of representation
     3158   is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is
     3159   preferred over 404 if the origin server knows, presumably through some
     3160   configurable means, that the condition is likely to be permanent.
    31543161</t>
    31553162</section>
    … …  
    31593166  <x:anchor-alias value="405 (Method Not Allowed)"/>
    31603167<t>
    3161    The method specified in the request-line is not allowed for the target
    3162    resource. The response &MUST; include an <x:ref>Allow</x:ref> header field
    3163    containing a list of valid methods for the requested resource.
     3168   The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the
     3169   method specified in the request-line is not allowed by the origin server
     3170   for the <x:ref>target resource</x:ref>. The origin server &MUST; generate
     3171   an <x:ref>Allow</x:ref> header field in the response containing a list of
     3172   valid methods for the requested resource.
    31643173</t>
    31653174</section>
    … …  
    31693178  <x:anchor-alias value="406 (Not Acceptable)"/>
    31703179<t>
    3171    The resource identified by the request is only capable of generating
    3172    response representations which have content characteristics not acceptable
    3173    according to the <x:ref>Accept</x:ref> and Accept-* header fields sent in
    3174    the request.
    3175 </t>
    3176 <t>
    3177    Unless it was a HEAD request, the response &SHOULD; include a representation
    3178    containing a list of available representation characteristics and location(s)
    3179    from which the user or user agent can choose the one most
    3180    appropriate. Depending upon the format and the
    3181    capabilities of the user agent, selection of the most appropriate
    3182    choice &MAY; be performed automatically. However, this specification
    3183    does not define any standard for such automatic selection.
    3184 </t>
    3185 <x:note>
    3186   <t>
    3187     &Note; HTTP/1.1 servers are allowed to send responses which are
    3188     not acceptable according to the accept header fields sent in the
    3189     request. In some cases, this might even be preferable to sending a
    3190     406 response. User agents are encouraged to inspect the header fields of
    3191     an incoming response to determine if it is acceptable.
    3192   </t>
    3193 </x:note>
    3194 <t>
    3195    If the response could be unacceptable, a user agent &SHOULD;
    3196    temporarily stop receipt of more data and query the user for a
    3197    decision on further actions.
     3180   The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the
     3181   <x:ref>target resource</x:ref> does not have a current representation which
     3182   would be acceptable to the user agent, according to the
     3183   <x:ref>proactive negotiation</x:ref> header fields received in the request
     3184   (<xref target="request.conneg"/>), and the server is unwilling to supply a
     3185   default representation.
     3186</t>
     3187<t>
     3188   The server &SHOULD; generate a payload containing a list of available
     3189   representation characteristics and corresponding resource identifiers from
     3190   which the user or user agent can choose the one most appropriate.
     3191   A user agent &MAY; automatically select the most appropriate choice from
     3192   that list. However, this specification does not define any standard for
     3193   such automatic selection. [The original proposal for 406 defined the
     3194   Alternates header field as providing a list of alternative representations,
     3195   such that it would be available for responses to the HEAD method, but lack
     3196   of deployment led to Alternates being dropped from the specification.]
    31983197</t>
    31993198</section>
    … …  
    32013200<section title="408 Request Timeout" anchor="status.408">
    32023201  <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/>
    3203 <t>
    3204    The server did not receive a complete request message within the time that
    3205    it was prepared to wait. If the client has sent a request, it &MAY; repeat
    3206    that request, possibly on a new connection if the server indicates that the
    3207    present connection is being closed.
     3202  <x:anchor-alias value="408 (Request Timeout)"/>
     3203<t>
     3204   The <x:dfn>408 (Request Timeout)</x:dfn> status code indicates
     3205   that the server did not receive a complete request message within the time
     3206   that it was prepared to wait. Since the only reason to send this message
     3207   is if the server has decided to close the connection, the server &SHOULD;
     3208   indicate that intent with the <x:ref>close</x:ref> connection option
     3209   (&header-connection;). If the client has an outstanding request in transit,
     3210   the client &MAY; repeat that request on a new connection.
    32083211</t>
    32093212</section>
    … …  
    32133216  <x:anchor-alias value="409 (Conflict)"/>
    32143217<t>
    3215    The request could not be completed due to a conflict with the current
    3216    state of the resource. This code is only allowed in situations where
    3217    it is expected that the user might be able to resolve the conflict
    3218    and resubmit the request. The payload &SHOULD; include enough
    3219    information for the user to recognize the source of the conflict.
    3220    Ideally, the response representation would include enough information for the
    3221    user or user agent to fix the problem; however, that might not be
    3222    possible and is not required.
     3218   The <x:dfn>409 (Conflict)</x:dfn> status code indicates that the request
     3219   could not be completed due to a conflict with the current state of the
     3220   resource. This code is only reasonable in situations where it is expected
     3221   that the user might be able to resolve the conflict and resubmit the
     3222   request. The server &SHOULD; generate a payload that includes enough
     3223   information for the user to recognize the source of the conflict. Ideally,
     3224   the response would include enough information for the user or user agent to
     3225   fix the problem; however, that might not be possible and is not required.
    32233226</t>
    32243227<t>
    … …  
    32373240  <x:anchor-alias value="410 (Gone)"/>
    32383241<t>
    3239    The target resource is no longer available at the server and no
    3240    forwarding address is known. This condition is expected to be
    3241    considered permanent. Clients with link editing capabilities &SHOULD;
    3242    delete references to the effective request URI after user approval. If the
    3243    server does not know, or has no facility to determine, whether or not
    3244    the condition is permanent, the status code <x:ref>404 (Not Found)</x:ref>
    3245    &SHOULD; be used instead.
     3242   The <x:dfn>410 (Gone)</x:dfn> status code indicates that access to the
     3243   <x:ref>target resource</x:ref> is no longer available at the origin
     3244   server and that this condition is likely to be permanent. If the origin
     3245   server does not know, or has no facility to determine, whether or not the
     3246   condition is permanent, the status code <x:ref>404 (Not Found)</x:ref>
     3247   ought to be used instead.
    32463248</t>
    32473249<t>
    … …  
    32513253   remote links to that resource be removed. Such an event is common for
    32523254   limited-time, promotional services and for resources belonging to
    3253    individuals no longer working at the server's site. It is not
     3255   individuals no longer associated with the origin server's site. It is not
    32543256   necessary to mark all permanently unavailable resources as "gone" or
    32553257   to keep the mark for any length of time &mdash; that is left to the
    … …  
    32663268  <x:anchor-alias value="411 (Length Required)"/>
    32673269<t>
    3268    The server refuses to accept the request without a defined
    3269    <x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it
    3270    adds a valid Content-Length header field containing the length of the
    3271    message body in the request message.
    3272 </t>
    3273 </section>
    3274 
    3275 <section title="413 Request Representation Too Large" anchor="status.413">
    3276   <iref primary="true" item="413 Request Representation Too Large (status code)" x:for-anchor=""/>
    3277 <t>
    3278    The server is refusing to process a request because the request
    3279    representation is larger than the server is willing or able to process. The
    3280    server &MAY; close the connection to prevent the client from continuing
     3270   The <x:dfn>411 (Length Required)</x:dfn> status code indicates that the
     3271   server refuses to accept the request without a defined
     3272   <x:ref>Content-Length</x:ref> (&header-content-length;).
     3273   The client &MAY; repeat the request if it adds a valid Content-Length
     3274   header field containing the length of the message body in the request
     3275   message.
     3276</t>
     3277</section>
     3278
     3279<section title="413 Request Payload Too Large" anchor="status.413">
     3280  <iref primary="true" item="413 Request Payload Too Large (status code)" x:for-anchor=""/>
     3281  <x:anchor-alias value="413 (Request Payload Too Large)"/>
     3282<t>
     3283   The <x:dfn>413 (Request Payload Too Large)</x:dfn> status code indicates
     3284   that the server is refusing to process a request because the request
     3285   payload is larger than the server is willing or able to process.
     3286   The server &MAY; close the connection to prevent the client from continuing
    32813287   the request.
    32823288</t>
    32833289<t>
    3284    If the condition is temporary, the server &SHOULD; include a
    3285    <x:ref>Retry-After</x:ref> header field to indicate that it is temporary and
    3286    after what time the client &MAY; try again.
     3290   If the condition is temporary, the server &SHOULD; generate a
     3291   <x:ref>Retry-After</x:ref> header field to indicate that it is temporary
     3292   and after what time the client &MAY; try again.
    32873293</t>
    32883294</section>
    … …  
    32923298  <x:anchor-alias value="414 (URI Too Long)"/>
    32933299<t>
    3294    The server is refusing to service the request because the effective request URI
    3295    is longer than the server is willing to interpret. This rare
    3296    condition is only likely to occur when a client has improperly
    3297    converted a POST request to a GET request with long query
    3298    information, when the client has descended into a URI "black hole" of
     3300   The <x:dfn>414 (URI Too Long)</x:dfn> status code indicates that the server
     3301   is refusing to service the request because the
     3302   request-target (&request-target;) is longer than the server is willing to
     3303   interpret. This rare condition is only likely to occur when a client has
     3304   improperly converted a POST request to a GET request with long query
     3305   information, when the client has descended into a "black hole" of
    32993306   redirection (e.g., a redirected URI prefix that points to a suffix of
    33003307   itself), or when the server is under attack by a client attempting to
    3301    exploit security holes present in some servers using fixed-length
    3302    buffers for reading or manipulating the request-target.
     3308   exploit security holes present in some servers using fixed-length buffers
     3309   for reading or manipulating the request-target.
    33033310</t>
    33043311</section>
    … …  
    33083315  <x:anchor-alias value="415 (Unsupported Media Type)"/>
    33093316<t>
    3310    The server is refusing to service the request because the request
    3311    payload is in a format not supported by this request method on the
    3312    target resource. The format problem might be due to the request's
    3313    indicated <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>,
    3314    or as a result of inspecting the data directly.
     3317   The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that
     3318   the origin server is refusing to service the request because the payload is
     3319   in a format not supported by the <x:ref>target resource</x:ref> for this
     3320   method. The format problem might be due to the request's indicated
     3321   <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a
     3322   result of inspecting the data directly.
    33153323</t>
    33163324</section>
    … …  
    33203328  <x:anchor-alias value="417 (Expectation Failed)"/>
    33213329<t>
    3322    The expectation given in an <x:ref>Expect</x:ref> header field (see
    3323    <xref target="header.expect"/>) could not be met by this server, or, if the
    3324    server is a proxy, the server has unambiguous evidence that the request
    3325    could not be met by the next-hop server.
     3330   The <x:dfn>417 (Expectation Failed)</x:dfn> status code indicates that the
     3331   expectation given in the request's <x:ref>Expect</x:ref> header field
     3332   (<xref target="header.expect"/>) could not be met by at least one of the
     3333   inbound servers.
    33263334</t>
    33273335</section>
    … …  
    33313339  <x:anchor-alias value="426 (Upgrade Required)"/>
    33323340<t>
    3333    The request can not be completed without a prior protocol upgrade. This
    3334    response &MUST; include an <x:ref>Upgrade</x:ref> header field
    3335    (&header-upgrade;) specifying the required protocols.
     3341   The <x:dfn>426 (Upgrade Required)</x:dfn> status code indicates that the
     3342   server refuses to perform the request using the current protocol but might
     3343   be willing to do so after the client upgrades to a different protocol.
     3344   The server &MUST; send an <x:ref>Upgrade</x:ref> header field in a 426
     3345   response to indicate the required protocol(s) (&header-upgrade;).
    33363346</t>
    33373347<figure>
    … …  
    33463356<x:span anchor="s426body">This service requires use of the HTTP/3.0 protocol.
    33473357</x:span></artwork></figure>
    3348 <t>
    3349    The server &SHOULD; include a message body in the 426 response which
    3350    indicates in human readable form the reason for the error and describes any
    3351    alternative courses which might be available to the user.
    3352 </t>
    33533358</section>
    33543359</section>
    … …  
    33603365  <iref primary="true" item="Status Codes Classes" subitem="5xx Server Error" x:for-anchor=""/>
    33613366<t>
    3362    Response status codes beginning with the digit "5" indicate cases in
    3363    which the server is aware that it has erred or is incapable of
    3364    performing the request. Except when responding to a HEAD request, the
     3367   The <x:dfn>5xx (Server Error)</x:dfn> class of status code indicates that
     3368   the server is aware that it has erred or is incapable of
     3369   performing the requested method. Except when responding to a HEAD request, the
    33653370   server &SHOULD; include a representation containing an explanation of the
    33663371   error situation, and whether it is a temporary or permanent
    … …  
    34633468   information about the response which cannot be placed in the status-line.
    34643469   These header fields give information about the server and about
    3465    further access to the target resource (&effective-request-uri;).
     3470   further access to the <x:ref>target resource</x:ref>.
    34663471</t>
    34673472
    … …  
    37923797<t><iref primary="true" item="selected representation"/>
    37933798   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    3794    the current representation of a target resource that would have been
     3799   the current representation of the <x:ref>target resource</x:ref> that would have been
    37953800   selected in a successful response if the same request had used the
    37963801   method GET and excluded any conditional request header fields.
    … …  
    38743879<t>
    38753880   The remaining response header fields provide more information about
    3876    the target resource for potential use in later requests.
     3881   the <x:ref>target resource</x:ref> for potential use in later requests.
    38773882</t>
    38783883<texttable align="left">
    … …  
    38893894<t>
    38903895   The "Allow" header field lists the set of methods advertised as
    3891    supported by the target resource. The purpose of this field is strictly to
     3896   supported by the <x:ref>target resource</x:ref>. The purpose of this field is strictly to
    38923897   inform the recipient of valid request methods associated with the resource.
    38933898</t>
    … …  
    42544259   </c>
    42554260   <c>413</c>
    4256    <c>Request Representation Too Large</c>
     4261   <c>Request Payload Too Large</c>
    42574262   <c>
    42584263      <xref target="status.413"/>
    … …  
    48134818  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    48144819  <x:source href="p1-messaging.xml" basename="p1-messaging">
     4820    <x:defines>close</x:defines>
    48154821    <x:defines>Connection</x:defines>
    48164822    <x:defines>Content-Length</x:defines>
Note: See TracChangeset for help on using the changeset viewer.