Ignore:
Timestamp:
Dec 27, 2012, 7:58:30 AM (7 years ago)
Author:
fielding@…
Message:

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

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.