Changeset 2057 for draft-ietf-httpbis
- Timestamp:
- 27/12/12 15:58:30 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2056 r2057 449 449 } 450 450 @bottom-center { 451 content: "Expires June 23, 2013";451 content: "Expires June 30, 2013"; 452 452 } 453 453 @bottom-right { … … 495 495 <meta name="dct.creator" content="Reschke, J. F."> 496 496 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-2 0">497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-27"> 498 498 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 499 499 <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."> … … 523 523 <tr> 524 524 <td class="left">Intended status: Standards Track</td> 525 <td class="right">December 2 0, 2012</td>525 <td class="right">December 27, 2012</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: June 23, 2013</td>528 <td class="left">Expires: June 30, 2013</td> 529 529 <td class="right"></td> 530 530 </tr> … … 554 554 in progress”. 555 555 </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> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 699 699 <li><a href="#rfc.section.6.5.9">6.5.9</a> <a href="#status.410">410 Gone</a></li> 700 700 <li><a href="#rfc.section.6.5.10">6.5.10</a> <a href="#status.411">411 Length Required</a></li> 701 <li><a href="#rfc.section.6.5.11">6.5.11</a> <a href="#status.413">413 Request RepresentationToo Large</a></li>701 <li><a href="#rfc.section.6.5.11">6.5.11</a> <a href="#status.413">413 Request Payload Too Large</a></li> 702 702 <li><a href="#rfc.section.6.5.12">6.5.12</a> <a href="#status.414">414 URI Too Long</a></li> 703 703 <li><a href="#rfc.section.6.5.13">6.5.13</a> <a href="#status.415">415 Unsupported Media Type</a></li> … … 1079 1079 <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>). 1080 1080 </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 only1082 act as an identifier for the payload's representation when a request is madevia 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. 1083 1083 </li> 1084 1084 <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 … … 1152 1152 by both the request method and the response status code. 1153 1153 </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 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 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 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 4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within 1156 1155 an HTML form. 1157 1156 </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 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 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 a1157 <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 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 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 1159 1158 current representation of the target resource after applying the processing. Response messages with an error status code usually 1160 1159 contain a representation that describes the error and what next steps are suggested for resolving it. … … 1206 1205 <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a> <a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3> 1207 1206 <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, 1209 1208 content-coding, etc.) compared to various information supplied in the request, including both the explicit negotiation fields 1210 1209 of <a href="#request.conneg" title="Content Negotiation">Section 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. … … 1262 1261 <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> 1263 1262 </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. 1267 1265 </p> 1268 1266 <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 … … 1390 1388 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="GET" href="#GET">GET</a></h3> 1391 1389 <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> 1393 1392 <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 1394 1393 of the process, unless that text happens to be the output of the process. … … 1422 1421 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="POST" href="#POST">POST</a></h3> 1423 1422 <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): 1425 1424 </p> 1426 1425 <ul> … … 1444 1443 <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a> <a id="PUT" href="#PUT">PUT</a></h3> 1445 1444 <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 representation1447 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on1448 that same target resource will result in an equivalentrepresentation 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 acted1445 <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 1449 1448 upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent 1450 1449 GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing … … 1507 1506 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1508 1507 <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 representations1510 or implementation. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI1511 mapping of the origin server, rather than an expectation that the information be deleted. The representations might or might1512 not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the1513 nature of the resource and its implementation by the origin server (which are beyondthe 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). 1514 1513 </p> 1515 1514 <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 … … 1721 1720 </ul> 1722 1721 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <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>. 1726 1724 </p> 1727 1725 <div id="rfc.table.u.4"> … … 2292 2290 <td class="left">413</td> 2293 2291 <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 RepresentationToo Large">Section 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 6.5.11</a></td> 2295 2293 </tr> 2296 2294 <tr> … … 2396 2394 <dl> 2397 2395 <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> 2399 2398 <dt>HEAD</dt> 2400 2399 <dd>the same representation as GET, except without the message body;</dd> … … 2438 2437 <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 2439 2438 <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. 2442 2440 </p> 2443 2441 <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 … … 2513 2511 <div id="rfc.iref.73"></div> 2514 2512 <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <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 representation2517 by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage2518 in reactive negotiation to select themost appropriate representation(s) for its needs (<a href="#content.negotiation" title="Content Negotiation">Section 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 3.4</a>). 2519 2517 </p> 2520 2518 <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 … … 2528 2526 <div id="rfc.iref.73"></div> 2529 2527 <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <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 resource2531 ought to use one of the enclosed URIs. Clients with link editing capabilities ought to automatically re-link references to2532 the effective request URI to one or more of thenew 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. 2533 2531 </p> 2534 2532 <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 … … 2564 2562 can be separately identified, bookmarked, and cached independent of the original request. 2565 2563 </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 2568 2565 to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what 2569 2566 can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP … … 2582 2579 <div id="rfc.iref.73"></div> 2583 2580 <h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a> <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 resourceresides 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, 2585 2582 the client ought to continue using the original effective request URI for future requests. 2586 2583 </p> … … 2602 2599 <div id="rfc.iref.74"></div> 2603 2600 <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a> <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> 2605 2604 <div id="rfc.iref.74"></div> 2606 2605 <h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> … … 2609 2608 <div id="rfc.iref.74"></div> 2610 2609 <h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a> <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>. 2617 2617 </p> 2618 2618 <div id="rfc.iref.74"></div> 2619 2619 <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a> <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. 2624 2623 </p> 2625 2624 <div id="rfc.iref.74"></div> 2626 2625 <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a> <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 fieldcontaining 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. 2628 2627 </p> 2629 2628 <div id="rfc.iref.74"></div> 2630 2629 <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a> <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 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.] 2645 2637 </p> 2646 2638 <div id="rfc.iref.74"></div> 2647 2639 <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a> <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 sent2649 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. 2650 2642 </p> 2651 2643 <div id="rfc.iref.74"></div> 2652 2644 <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a> <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. 2656 2650 </p> 2657 2651 <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 … … 2662 2656 <div id="rfc.iref.74"></div> 2663 2657 <h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a> <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. 2667 2660 </p> 2668 2661 <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 2669 2662 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's2671 site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time2672 — 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. 2673 2666 </p> 2674 2667 <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. … … 2676 2669 <div id="rfc.iref.74"></div> 2677 2670 <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a> <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 request2671 <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 2679 2672 message. 2680 2673 </p> 2681 2674 <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> <a id="status.413" href="#status.413">413 Request RepresentationToo 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 able2684 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> <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. 2687 2680 </p> 2688 2681 <div id="rfc.iref.74"></div> 2689 2682 <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a> <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. 2695 2687 </p> 2696 2688 <div id="rfc.iref.74"></div> 2697 2689 <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a> <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 method2699 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. 2700 2692 </p> 2701 2693 <div id="rfc.iref.74"></div> 2702 2694 <h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a> <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 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 5.1.2</a>) could not be met by at least one of the inbound servers. 2705 2696 </p> 2706 2697 <div id="rfc.iref.74"></div> 2707 2698 <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 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>). 2709 2701 </p> 2710 2702 <div id="rfc.figure.u.41"></div> … … 2716 2708 2717 2709 <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> <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> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> 2722 2711 <div id="rfc.iref.74"></div> 2723 2712 <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 incapable2725 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. 2726 2715 User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. 2727 2716 </p> … … 2765 2754 <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 2766 2755 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.2 5"><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. 2768 2757 </p> 2769 2758 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2770 2759 <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>. 2772 2761 </p> 2773 2762 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 2963 2952 </pre><p id="rfc.section.7.1.3.p.8">In the latter example, the delay is 2 minutes.</p> 2964 2953 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <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 if2966 the same request had used the method GET and excluded any conditionalrequest 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. 2967 2956 </p> 2968 2957 <p id="rfc.section.7.2.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included … … 3041 3030 </div> 3042 3031 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <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> 3044 3034 <div id="rfc.table.u.13"> 3045 3035 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 3068 3058 <div id="rfc.iref.a.5"></div> 3069 3059 <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <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. 3072 3061 </p> 3073 3062 <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> … … 3085 3074 </p> 3086 3075 <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.2 7"><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 identifiers3076 </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 3088 3077 are listed in order of their significance for identifying the origin server software. Each product identifier consists of 3089 3078 a name and optional version, as defined in <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 5.5.3</a>. … … 3118 3107 to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3119 3108 </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 the3109 <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 3121 3110 parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of 3122 3111 new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a … … 3387 3376 <tr> 3388 3377 <td class="left">413</td> 3389 <td class="left">Request RepresentationToo Large</td>3390 <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request RepresentationToo Large">Section 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 6.5.11</a> 3391 3380 </td> 3392 3381 </tr> … … 3459 3448 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3460 3449 <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. 3462 3451 </p> 3463 3452 <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 … … 3466 3455 processing, since the prefix would ensure that private names never collide with a newly registered Internet name.) 3467 3456 </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.3 0"><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 characters3457 <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 3469 3458 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>. 3470 3459 </p> 3471 3460 <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 3472 3461 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.3 1"><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>). 3474 3463 </p> 3475 3464 <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 … … 3489 3478 <ul> 3490 3479 <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.3 2"><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>). 3492 3481 </p> 3493 3482 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 3505 3494 </li> 3506 3495 <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.3 3"><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>). 3508 3497 </p> 3509 3498 </li> … … 3516 3505 </li> 3517 3506 <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.3 4"><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>). 3519 3508 </p> 3520 3509 </li> … … 3682 3671 <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> 3683 3672 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h2> 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.3 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.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 <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3685 3674 </p> 3686 3675 <h3 id="rfc.section.8.4.1"><a href="#rfc.section.8.4.1">8.4.1</a> <a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3> … … 3692 3681 <li>Pointer to specification text</li> 3693 3682 </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.3 6"><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>). 3695 3684 </p> 3696 3685 <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. … … 3712 3701 <td class="left">compress</td> 3713 3702 <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> 3715 3704 </td> 3716 3705 </tr> … … 3719 3708 <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>) 3720 3709 </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> 3722 3711 </td> 3723 3712 </tr> … … 3725 3714 <td class="left">gzip</td> 3726 3715 <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.4 0"><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> 3728 3717 </td> 3729 3718 </tr> … … 3817 3806 </p> 3818 3807 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <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.4 1"><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>. 3820 3809 </p> 3821 3810 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 4155 4144 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 7.4.1</a>) 4156 4145 </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.4 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.4.2</a>)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 7.4.2</a>) 4158 4147 </p> 4159 4148 <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) … … 4180 4169 (any visible US-ASCII character). 4181 4170 </p> 4182 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 3"><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> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4185 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4186 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4187 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4188 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1. 48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4189 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1. 49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4190 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 0"><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>>4191 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4192 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4193 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4194 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>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> = <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>> 4174 <a href="#imported.abnf" class="smpl">OWS</a> = <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>> 4175 <a href="#imported.abnf" class="smpl">RWS</a> = <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>> 4176 <a href="#imported.abnf" class="smpl">URI-reference</a> = <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>> 4177 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <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>> 4178 <a href="#imported.abnf" class="smpl">comment</a> = <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>> 4179 <a href="#imported.abnf" class="smpl">field-name</a> = <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>> 4180 <a href="#imported.abnf" class="smpl">partial-URI</a> = <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>> 4181 <a href="#imported.abnf" class="smpl">quoted-string</a> = <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>> 4182 <a href="#imported.abnf" class="smpl">token</a> = <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>> 4183 <a href="#imported.abnf" class="smpl">word</a> = <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>> 4195 4184 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4196 4185 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4390 4379 <li>410 Gone (status code) <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> 4391 4380 <li>411 Length Required (status code) <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 RepresentationToo Large (status code) <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) <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> 4393 4382 <li>414 URI Too Long (status code) <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> 4394 4383 <li>415 Unsupported Media Type (status code) <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> … … 4544 4533 </li> 4545 4534 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4546 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5. 15</a>, <a href="#rfc.xref.Part1.25">6.6.6</a>, <a href="#rfc.xref.Part1.26">7</a>, <a href="#rfc.xref.Part1.27">7.4.2</a>, <a href="#rfc.xref.Part1.28">8.1.2</a>, <a href="#rfc.xref.Part1.29">8.3.1</a>, <a href="#rfc.xref.Part1.30">8.3.1</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.4</a>, <a href="#rfc.xref.Part1.36">8.4.1</a>, <a href="#rfc.xref.Part1.37">8.4.1</a>, <a href="#rfc.xref.Part1.38">8.4.2</a>, <a href="#rfc.xref.Part1.39">8.4.2</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.42">C</a>, <a href="#rfc.xref.Part1.43">D</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a><ul>4535 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.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> 4547 4536 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 4548 4537 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 4549 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.2 5">6.6.6</a></li>4550 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.4 7">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> <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.2 7">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> <a href="#rfc.xref.Part1.4 4">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> <a href="#rfc.xref.Part1.3 1">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> <a href="#rfc.xref.Part1.28">6.6.6</a></li> 4539 <li><em>Section 2.7</em> <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> <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> <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> <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> 4554 4543 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li> 4555 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1. 28">8.1.2</a></li>4556 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.13">3.3</a> </li>4557 <li><em>Section 4</em> <a href="#rfc.xref.Part1.3 6">8.4.1</a></li>4558 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.3 4">8.3.1</a></li>4559 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1. 38">8.4.2</a></li>4560 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.3 5">8.4</a>, <a href="#rfc.xref.Part1.37">8.4.1</a></li>4561 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1. 39">8.4.2</a></li>4562 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.4 0">8.4.2</a></li>4544 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.30">8.1.2</a></li> 4545 <li><em>Section 3.3.2</em> <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> <a href="#rfc.xref.Part1.38">8.4.1</a></li> 4547 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.36">8.3.1</a></li> 4548 <li><em>Section 4.2.1</em> <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> <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> <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> <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.42">8.4.2</a></li> 4563 4552 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">5.5</a></li> 4564 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a> </li>4553 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.26">6.5.12</a></li> 4565 4554 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 4566 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a> , <a href="#rfc.xref.Part1.26">7</a></li>4567 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.4 2">C</a></li>4555 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li> 4556 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li> 4568 4557 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.23">6.3.4</a></li> 4569 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1. 33">8.3.1</a></li>4570 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.2 4">6.5.15</a></li>4558 <li><em>Section 6.1</em> <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> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.27">6.5.15</a></li> 4571 4560 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a></li> 4572 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 1">10</a></li>4573 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.3 0">8.3.1</a></li>4561 <li><em>Section 9</em> <a href="#rfc.xref.Part1.43">10</a></li> 4562 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.32">8.3.1</a></li> 4574 4563 </ul> 4575 4564 </li> … … 4725 4714 </li> 4726 4715 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 4727 <li>TRACE method <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 <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> 4728 4717 </ul> 4729 4718 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2056 r2057 718 718 <t>If the request is GET or HEAD and the response status code is 719 719 <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is a 720 potentially modified representation of the target resource; as such,721 the effective request URI might only act as an identifier for the722 payload's representation when a request is made via the same chain723 of intermediaries.</t>720 potentially modified representation of the 721 <x:ref>target resource</x:ref>; as such, the effective request URI 722 might only act as an identifier for the payload's representation when 723 a request is made via the same chain of intermediaries.</t> 724 724 <t>If the response has a <x:ref>Content-Location</x:ref> header field 725 725 and its field-value is a reference to the same URI as the effective … … 864 864 <t> 865 865 For example, a representation in the payload of a PUT request 866 (<xref target="PUT"/>) represents the desired state of the target resource866 (<xref target="PUT"/>) represents the desired state of the <x:ref>target resource</x:ref> 867 867 if the request is successfully applied, whereas a representation in the 868 868 payload of a POST request (<xref target="POST"/>) represents an anonymous … … 872 872 <t> 873 873 Likewise, the payload of a <x:ref>200 (OK)</x:ref> response to GET 874 (<xref target="GET"/>) contains a representation of the target resource,874 (<xref target="GET"/>) contains a representation of the <x:ref>target resource</x:ref>, 875 875 as observed at the time of the message origination date 876 876 (<xref target="header.date"/>), whereas the same status code in a response … … 940 940 (a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on 941 941 the available representations for a response (the dimensions over which it 942 might vary ; e.g.,language, content-coding, etc.) compared to various942 might vary, such as language, content-coding, etc.) compared to various 943 943 information supplied in the request, including both the explicit 944 944 negotiation fields of <xref target="request.conneg"/> and implicit … … 1056 1056 HTTP was originally designed to be usable as an interface to distributed 1057 1057 object systems. The request method was envisioned as applying 1058 semantics to a target resourcein much the same way as invoking a defined1058 semantics to a <x:ref>target resource</x:ref> in much the same way as invoking a defined 1059 1059 method on an identified object would apply semantics. The method token 1060 1060 is case-sensitive because it might be used as a gateway to object-based … … 1239 1239 <t> 1240 1240 The GET method requests transfer of a current representation of 1241 the target resource.1241 the <x:ref>target resource</x:ref>. 1242 1242 </t> 1243 1243 <t> … … 1313 1313 The POST method requests that the origin server accept the 1314 1314 representation enclosed in the request as data to be processed by the 1315 target resource. For example, POST is frequently used for the following1315 <x:ref>target resource</x:ref>. For example, POST is frequently used for the following 1316 1316 functions (among others): 1317 1317 <list style="symbols"> … … 1370 1370 <iref primary="true" item="PUT method" x:for-anchor=""/> 1371 1371 <t> 1372 The PUT method requests that the state of the target resource1372 The PUT method requests that the state of the <x:ref>target resource</x:ref> 1373 1373 be created or replaced with the state defined by the representation 1374 1374 enclosed in the request message payload. A successful PUT of a given … … 1498 1498 <t> 1499 1499 The DELETE method requests that the origin server remove the association 1500 between the target resourceand its current representations or1500 between the <x:ref>target resource</x:ref> and its current representations or 1501 1501 implementation. In effect, this method is similar to the rm command in 1502 1502 UNIX: it expresses a deletion operation on the URI mapping of the … … 1936 1936 <t> 1937 1937 Conditionals are request header fields that indicate a precondition to be 1938 tested before applying the method semantics to the target resource.1938 tested before applying the method semantics to the <x:ref>target resource</x:ref>. 1939 1939 Each precondition is based on metadata that is expected to change if the 1940 1940 selected representation of the target resource is changed. The HTTP/1.1 … … 2671 2671 <list style="hanging"> 2672 2672 <t hangText="GET"> 2673 a representation of the target resource is sent in the response;2673 a representation of the <x:ref>target resource</x:ref>; 2674 2674 </t> 2675 2675 <t hangText="HEAD"> … … 2763 2763 has successfully fulfilled the request and that there is no additional 2764 2764 content to send in the response payload body. Metadata in the response 2765 header fields refer to the target resourceand its current representation2765 header fields refer to the <x:ref>target resource</x:ref> and its current representation 2766 2766 after the requested action. 2767 2767 </t> … … 2911 2911 <t> 2912 2912 The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the 2913 target resourcehas more than one representation, each with its own more2913 <x:ref>target resource</x:ref> has more than one representation, each with its own more 2914 2914 specific identifier, and information about the alternatives is being 2915 2915 provided so that the user (or user agent) can select a preferred … … 2946 2946 <t> 2947 2947 The <x:dfn>301 (Moved Permanently)</x:dfn> status code indicates that the 2948 target resource has been assigned a new permanent URI and any future2949 references to this resource ought to use one of the enclosed URIs. Clients2950 with link editing capabilities ought to automatically re-link references to2951 the effective request URI to one or more of the new references sent by the2952 server, where possible.2948 <x:ref>target resource</x:ref> has been assigned a new permanent URI and 2949 any future references to this resource ought to use one of the enclosed 2950 URIs. Clients with link editing capabilities ought to automatically re-link 2951 references to the effective request URI to one or more of the new 2952 references sent by the server, where possible. 2953 2953 </t> 2954 2954 <t> … … 3023 3023 </t> 3024 3024 <t> 3025 A 303 response to a GET request indicates that the requested3026 resource does not have a representation of its own that can be3027 transferred by the server over HTTP. The <x:ref>Location</x:ref> URI3028 indicates a resource that is descriptive of the target resource, such that3029 the follow-on representation might be useful to recipients without3030 implying that it adequately represents the target resource.3031 Note that answers to the questions of what can be represented, what3032 represent ations are adequate, and what might be a useful description3033 are outside the scope of HTTP and thus entirely determined by the3034 URI owner(s).3025 A 303 response to a GET request indicates that the 3026 <x:ref>target resource</x:ref> resource does not have a representation of 3027 its own that can be transferred by the server over HTTP. 3028 The <x:ref>Location</x:ref> URI identifies a resource that is descriptive 3029 of the target resource, such that the follow-on representation might be 3030 useful to recipients without implying that it adequately represents the 3031 target resource. Note that answers to the questions of what can be 3032 represented, what representations are adequate, and what might be a useful 3033 description are outside the scope of HTTP and thus entirely determined by 3034 the URI owner(s). 3035 3035 </t> 3036 3036 <t> … … 3065 3065 <t> 3066 3066 The <x:dfn>307 (Temporary Redirect)</x:dfn> status code indicates that the 3067 target resource resides temporarily under a different URI and the3068 user agent &MUST-NOT; change the request method if it performs an automatic3069 redirection to that URI.3067 <x:ref>target resource</x:ref> resides temporarily under a different URI 3068 and the user agent &MUST-NOT; change the request method if it performs an 3069 automatic redirection to that URI. 3070 3070 Since the redirection can change over time, the client ought to continue 3071 3071 using the original effective request URI for future requests. … … 3108 3108 <x:anchor-alias value="400 (Bad Request)"/> 3109 3109 <t> 3110 The server cannot or will not process the request, due to a client error (e.g., 3111 malformed syntax). 3110 The <x:dfn>400 (Bad Request)</x:dfn> status code indicates that the server 3111 cannot or will not process the request because the received syntax is 3112 invalid, nonsensical, or exceeds some limitation on what the server is 3113 willing to process. 3112 3114 </t> 3113 3115 </section> … … 3126 3128 <x:anchor-alias value="403 (Forbidden)"/> 3127 3129 <t> 3128 The server understood the request, but refuses to authorize it. Providing 3129 different user authentication credentials might be successful, but any 3130 credentials that were provided in the request are insufficient. The request 3131 &SHOULD-NOT; be repeated with the same credentials. 3132 </t> 3133 <t> 3134 If the request method was not HEAD and the server wishes to make 3135 public why the request has not been fulfilled, it &SHOULD; describe the 3136 reason for the refusal in the representation. If the server does not wish to 3137 make this information available to the client, the status code <x:ref>404 3138 (Not Found)</x:ref> &MAY; be used instead. 3130 The <x:dfn>403 (Forbidden)</x:dfn> status code indicates that the origin 3131 server understood the request but refuses to authorize it. 3132 A server that wishes to make public why the request has been forbidden 3133 can describe that reason in the response payload (if any). 3134 </t> 3135 <t> 3136 If authentication credentials were provided in the request, the origin 3137 server considers them insufficient to grant access. 3138 The client &SHOULD-NOT; repeat the request with the same credentials. 3139 The client &MAY; repeat the request with new or different credentials. 3140 However, a request might be forbidden for reasons unrelated to the 3141 credentials. 3142 </t> 3143 <t> 3144 An origin server that wishes to "hide" the current existence of a forbidden 3145 <x:ref>target resource</x:ref> &MAY; instead respond with a status 3146 code of <x:ref>404 (Not Found)</x:ref>. 3139 3147 </t> 3140 3148 </section> … … 3144 3152 <x:anchor-alias value="404 (Not Found)"/> 3145 3153 <t> 3146 The server has not found anything matching the effective request URI. No 3147 indication is given of whether the condition is temporary or 3148 permanent. The <x:ref>410 (Gone)</x:ref> status code &SHOULD; be used if the server 3149 knows, through some internally configurable mechanism, that an old 3150 resource is permanently unavailable and has no forwarding address. 3151 This status code is commonly used when the server does not wish to 3152 reveal exactly why the request has been refused, or when no other 3153 response is applicable. 3154 The <x:dfn>404 (Not Found)</x:dfn> status code indicates that the origin 3155 server did not find a current representation for the 3156 <x:ref>target resource</x:ref> or is not willing to disclose that one 3157 exists. A 404 status does not indicate whether this lack of representation 3158 is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is 3159 preferred over 404 if the origin server knows, presumably through some 3160 configurable means, that the condition is likely to be permanent. 3154 3161 </t> 3155 3162 </section> … … 3159 3166 <x:anchor-alias value="405 (Method Not Allowed)"/> 3160 3167 <t> 3161 The method specified in the request-line is not allowed for the target 3162 resource. The response &MUST; include an <x:ref>Allow</x:ref> header field 3163 containing a list of valid methods for the requested resource. 3168 The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the 3169 method specified in the request-line is not allowed by the origin server 3170 for the <x:ref>target resource</x:ref>. The origin server &MUST; generate 3171 an <x:ref>Allow</x:ref> header field in the response containing a list of 3172 valid methods for the requested resource. 3164 3173 </t> 3165 3174 </section> … … 3169 3178 <x:anchor-alias value="406 (Not Acceptable)"/> 3170 3179 <t> 3171 The resource identified by the request is only capable of generating 3172 response representations which have content characteristics not acceptable 3173 according to the <x:ref>Accept</x:ref> and Accept-* header fields sent in 3174 the request. 3175 </t> 3176 <t> 3177 Unless it was a HEAD request, the response &SHOULD; include a representation 3178 containing a list of available representation characteristics and location(s) 3179 from which the user or user agent can choose the one most 3180 appropriate. Depending upon the format and the 3181 capabilities of the user agent, selection of the most appropriate 3182 choice &MAY; be performed automatically. However, this specification 3183 does not define any standard for such automatic selection. 3184 </t> 3185 <x:note> 3186 <t> 3187 &Note; HTTP/1.1 servers are allowed to send responses which are 3188 not acceptable according to the accept header fields sent in the 3189 request. In some cases, this might even be preferable to sending a 3190 406 response. User agents are encouraged to inspect the header fields of 3191 an incoming response to determine if it is acceptable. 3192 </t> 3193 </x:note> 3194 <t> 3195 If the response could be unacceptable, a user agent &SHOULD; 3196 temporarily stop receipt of more data and query the user for a 3197 decision on further actions. 3180 The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the 3181 <x:ref>target resource</x:ref> does not have a current representation which 3182 would be acceptable to the user agent, according to the 3183 <x:ref>proactive negotiation</x:ref> header fields received in the request 3184 (<xref target="request.conneg"/>), and the server is unwilling to supply a 3185 default representation. 3186 </t> 3187 <t> 3188 The server &SHOULD; generate a payload containing a list of available 3189 representation characteristics and corresponding resource identifiers from 3190 which the user or user agent can choose the one most appropriate. 3191 A user agent &MAY; automatically select the most appropriate choice from 3192 that list. However, this specification does not define any standard for 3193 such automatic selection. [The original proposal for 406 defined the 3194 Alternates header field as providing a list of alternative representations, 3195 such that it would be available for responses to the HEAD method, but lack 3196 of deployment led to Alternates being dropped from the specification.] 3198 3197 </t> 3199 3198 </section> … … 3201 3200 <section title="408 Request Timeout" anchor="status.408"> 3202 3201 <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/> 3203 <t> 3204 The server did not receive a complete request message within the time that 3205 it was prepared to wait. If the client has sent a request, it &MAY; repeat 3206 that request, possibly on a new connection if the server indicates that the 3207 present connection is being closed. 3202 <x:anchor-alias value="408 (Request Timeout)"/> 3203 <t> 3204 The <x:dfn>408 (Request Timeout)</x:dfn> status code indicates 3205 that the server did not receive a complete request message within the time 3206 that it was prepared to wait. Since the only reason to send this message 3207 is if the server has decided to close the connection, the server &SHOULD; 3208 indicate that intent with the <x:ref>close</x:ref> connection option 3209 (&header-connection;). If the client has an outstanding request in transit, 3210 the client &MAY; repeat that request on a new connection. 3208 3211 </t> 3209 3212 </section> … … 3213 3216 <x:anchor-alias value="409 (Conflict)"/> 3214 3217 <t> 3215 The request could not be completed due to a conflict with the current3216 state of the resource. This code is only allowed in situations where3217 it is expected that the user might be able to resolve the conflict3218 and resubmit the request. The payload &SHOULD; include enough3219 information for the user to recognize the source of the conflict.3220 Ideally, the response representation would include enough information for the3221 user or user agent to fix the problem; however, that might not be3222 possible and is not required.3218 The <x:dfn>409 (Conflict)</x:dfn> status code indicates that the request 3219 could not be completed due to a conflict with the current state of the 3220 resource. This code is only reasonable in situations where it is expected 3221 that the user might be able to resolve the conflict and resubmit the 3222 request. The server &SHOULD; generate a payload that includes enough 3223 information for the user to recognize the source of the conflict. Ideally, 3224 the response would include enough information for the user or user agent to 3225 fix the problem; however, that might not be possible and is not required. 3223 3226 </t> 3224 3227 <t> … … 3237 3240 <x:anchor-alias value="410 (Gone)"/> 3238 3241 <t> 3239 The target resource is no longer available at the server and no 3240 forwarding address is known. This condition is expected to be 3241 considered permanent. Clients with link editing capabilities &SHOULD; 3242 delete references to the effective request URI after user approval. If the 3243 server does not know, or has no facility to determine, whether or not 3244 the condition is permanent, the status code <x:ref>404 (Not Found)</x:ref> 3245 &SHOULD; be used instead. 3242 The <x:dfn>410 (Gone)</x:dfn> status code indicates that access to the 3243 <x:ref>target resource</x:ref> is no longer available at the origin 3244 server and that this condition is likely to be permanent. If the origin 3245 server does not know, or has no facility to determine, whether or not the 3246 condition is permanent, the status code <x:ref>404 (Not Found)</x:ref> 3247 ought to be used instead. 3246 3248 </t> 3247 3249 <t> … … 3251 3253 remote links to that resource be removed. Such an event is common for 3252 3254 limited-time, promotional services and for resources belonging to 3253 individuals no longer working at theserver's site. It is not3255 individuals no longer associated with the origin server's site. It is not 3254 3256 necessary to mark all permanently unavailable resources as "gone" or 3255 3257 to keep the mark for any length of time — that is left to the … … 3266 3268 <x:anchor-alias value="411 (Length Required)"/> 3267 3269 <t> 3268 The server refuses to accept the request without a defined 3269 <x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it 3270 adds a valid Content-Length header field containing the length of the 3271 message body in the request message. 3272 </t> 3273 </section> 3274 3275 <section title="413 Request Representation Too Large" anchor="status.413"> 3276 <iref primary="true" item="413 Request Representation Too Large (status code)" x:for-anchor=""/> 3277 <t> 3278 The server is refusing to process a request because the request 3279 representation is larger than the server is willing or able to process. The 3280 server &MAY; close the connection to prevent the client from continuing 3270 The <x:dfn>411 (Length Required)</x:dfn> status code indicates that the 3271 server refuses to accept the request without a defined 3272 <x:ref>Content-Length</x:ref> (&header-content-length;). 3273 The client &MAY; repeat the request if it adds a valid Content-Length 3274 header field containing the length of the message body in the request 3275 message. 3276 </t> 3277 </section> 3278 3279 <section title="413 Request Payload Too Large" anchor="status.413"> 3280 <iref primary="true" item="413 Request Payload Too Large (status code)" x:for-anchor=""/> 3281 <x:anchor-alias value="413 (Request Payload Too Large)"/> 3282 <t> 3283 The <x:dfn>413 (Request Payload Too Large)</x:dfn> status code indicates 3284 that the server is refusing to process a request because the request 3285 payload is larger than the server is willing or able to process. 3286 The server &MAY; close the connection to prevent the client from continuing 3281 3287 the request. 3282 3288 </t> 3283 3289 <t> 3284 If the condition is temporary, the server &SHOULD; include a3285 <x:ref>Retry-After</x:ref> header field to indicate that it is temporary and3286 a fter what time the client &MAY; try again.3290 If the condition is temporary, the server &SHOULD; generate a 3291 <x:ref>Retry-After</x:ref> header field to indicate that it is temporary 3292 and after what time the client &MAY; try again. 3287 3293 </t> 3288 3294 </section> … … 3292 3298 <x:anchor-alias value="414 (URI Too Long)"/> 3293 3299 <t> 3294 The server is refusing to service the request because the effective request URI 3295 is longer than the server is willing to interpret. This rare 3296 condition is only likely to occur when a client has improperly 3297 converted a POST request to a GET request with long query 3298 information, when the client has descended into a URI "black hole" of 3300 The <x:dfn>414 (URI Too Long)</x:dfn> status code indicates that the server 3301 is refusing to service the request because the 3302 request-target (&request-target;) is longer than the server is willing to 3303 interpret. This rare condition is only likely to occur when a client has 3304 improperly converted a POST request to a GET request with long query 3305 information, when the client has descended into a "black hole" of 3299 3306 redirection (e.g., a redirected URI prefix that points to a suffix of 3300 3307 itself), or when the server is under attack by a client attempting to 3301 exploit security holes present in some servers using fixed-length 3302 buffersfor reading or manipulating the request-target.3308 exploit security holes present in some servers using fixed-length buffers 3309 for reading or manipulating the request-target. 3303 3310 </t> 3304 3311 </section> … … 3308 3315 <x:anchor-alias value="415 (Unsupported Media Type)"/> 3309 3316 <t> 3310 The server is refusing to service the request because the request 3311 payload is in a format not supported by this request method on the 3312 target resource. The format problem might be due to the request's 3313 indicated <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, 3314 or as a result of inspecting the data directly. 3317 The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that 3318 the origin server is refusing to service the request because the payload is 3319 in a format not supported by the <x:ref>target resource</x:ref> for this 3320 method. The format problem might be due to the request's indicated 3321 <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a 3322 result of inspecting the data directly. 3315 3323 </t> 3316 3324 </section> … … 3320 3328 <x:anchor-alias value="417 (Expectation Failed)"/> 3321 3329 <t> 3322 The expectation given in an <x:ref>Expect</x:ref> header field (see3323 <xref target="header.expect"/>) could not be met by this server, or, if the3324 server is a proxy, the server has unambiguous evidence that the request3325 could not be met by the next-hop server.3330 The <x:dfn>417 (Expectation Failed)</x:dfn> status code indicates that the 3331 expectation given in the request's <x:ref>Expect</x:ref> header field 3332 (<xref target="header.expect"/>) could not be met by at least one of the 3333 inbound servers. 3326 3334 </t> 3327 3335 </section> … … 3331 3339 <x:anchor-alias value="426 (Upgrade Required)"/> 3332 3340 <t> 3333 The request can not be completed without a prior protocol upgrade. This 3334 response &MUST; include an <x:ref>Upgrade</x:ref> header field 3335 (&header-upgrade;) specifying the required protocols. 3341 The <x:dfn>426 (Upgrade Required)</x:dfn> status code indicates that the 3342 server refuses to perform the request using the current protocol but might 3343 be willing to do so after the client upgrades to a different protocol. 3344 The server &MUST; send an <x:ref>Upgrade</x:ref> header field in a 426 3345 response to indicate the required protocol(s) (&header-upgrade;). 3336 3346 </t> 3337 3347 <figure> … … 3346 3356 <x:span anchor="s426body">This service requires use of the HTTP/3.0 protocol. 3347 3357 </x:span></artwork></figure> 3348 <t>3349 The server &SHOULD; include a message body in the 426 response which3350 indicates in human readable form the reason for the error and describes any3351 alternative courses which might be available to the user.3352 </t>3353 3358 </section> 3354 3359 </section> … … 3360 3365 <iref primary="true" item="Status Codes Classes" subitem="5xx Server Error" x:for-anchor=""/> 3361 3366 <t> 3362 Response status codes beginning with the digit "5" indicate cases in3363 whichthe server is aware that it has erred or is incapable of3364 performing the request . Except when responding to a HEAD request, the3367 The <x:dfn>5xx (Server Error)</x:dfn> class of status code indicates that 3368 the server is aware that it has erred or is incapable of 3369 performing the requested method. Except when responding to a HEAD request, the 3365 3370 server &SHOULD; include a representation containing an explanation of the 3366 3371 error situation, and whether it is a temporary or permanent … … 3463 3468 information about the response which cannot be placed in the status-line. 3464 3469 These header fields give information about the server and about 3465 further access to the target resource (&effective-request-uri;).3470 further access to the <x:ref>target resource</x:ref>. 3466 3471 </t> 3467 3472 … … 3792 3797 <t><iref primary="true" item="selected representation"/> 3793 3798 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the 3794 the current representation of a target resourcethat would have been3799 the current representation of the <x:ref>target resource</x:ref> that would have been 3795 3800 selected in a successful response if the same request had used the 3796 3801 method GET and excluded any conditional request header fields. … … 3874 3879 <t> 3875 3880 The remaining response header fields provide more information about 3876 the target resourcefor potential use in later requests.3881 the <x:ref>target resource</x:ref> for potential use in later requests. 3877 3882 </t> 3878 3883 <texttable align="left"> … … 3889 3894 <t> 3890 3895 The "Allow" header field lists the set of methods advertised as 3891 supported by the target resource. The purpose of this field is strictly to3896 supported by the <x:ref>target resource</x:ref>. The purpose of this field is strictly to 3892 3897 inform the recipient of valid request methods associated with the resource. 3893 3898 </t> … … 4254 4259 </c> 4255 4260 <c>413</c> 4256 <c>Request RepresentationToo Large</c>4261 <c>Request Payload Too Large</c> 4257 4262 <c> 4258 4263 <xref target="status.413"/> … … 4813 4818 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> 4814 4819 <x:source href="p1-messaging.xml" basename="p1-messaging"> 4820 <x:defines>close</x:defines> 4815 4821 <x:defines>Connection</x:defines> 4816 4822 <x:defines>Content-Length</x:defines>
Note: See TracChangeset
for help on using the changeset viewer.