Changeset 1840
- Timestamp:
- 27/08/12 06:21:21 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1839 r1840 449 449 } 450 450 @bottom-center { 451 content: "Expires February 2 6, 2013";451 content: "Expires February 27, 2013"; 452 452 } 453 453 @bottom-right { … … 499 499 <meta name="dct.creator" content="Reschke, J. F."> 500 500 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 501 <meta name="dct.issued" scheme="ISO8601" content="2012-08-2 5">501 <meta name="dct.issued" scheme="ISO8601" content="2012-08-26"> 502 502 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 503 503 <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."> … … 530 530 </tr> 531 531 <tr> 532 <td class="left">Expires: February 2 6, 2013</td>532 <td class="left">Expires: February 27, 2013</td> 533 533 <td class="right">greenbytes</td> 534 534 </tr> 535 535 <tr> 536 536 <td class="left"></td> 537 <td class="right">August 2 5, 2012</td>537 <td class="right">August 26, 2012</td> 538 538 </tr> 539 539 </tbody> … … 562 562 in progress”. 563 563 </p> 564 <p>This Internet-Draft will expire on February 2 6, 2013.</p>564 <p>This Internet-Draft will expire on February 27, 2013.</p> 565 565 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 566 566 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 590 590 <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#safe.methods">Safe Methods</a></li> 591 591 <li><a href="#rfc.section.3.1.2">3.1.2</a> <a href="#idempotent.methods">Idempotent Methods</a></li> 592 <li><a href="#rfc.section.3.1.3">3.1.3</a> <a href="#cacheable.methods">Cacheable Methods</a></li> 592 593 </ul> 593 594 </li> 594 <li><a href="#rfc.section.3.2">3.2</a> <a href="#method.registry">Method Registry</a><ul> 595 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#considerations.for.new.methods">Considerations for New Methods</a></li> 596 </ul> 597 </li> 598 <li><a href="#rfc.section.3.3">3.3</a> <a href="#method.definitions">Method Definitions</a><ul> 599 <li><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#OPTIONS">OPTIONS</a></li> 600 <li><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#GET">GET</a></li> 601 <li><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#HEAD">HEAD</a></li> 602 <li><a href="#rfc.section.3.3.4">3.3.4</a> <a href="#POST">POST</a></li> 603 <li><a href="#rfc.section.3.3.5">3.3.5</a> <a href="#PUT">PUT</a></li> 604 <li><a href="#rfc.section.3.3.6">3.3.6</a> <a href="#DELETE">DELETE</a></li> 605 <li><a href="#rfc.section.3.3.7">3.3.7</a> <a href="#TRACE">TRACE</a></li> 606 <li><a href="#rfc.section.3.3.8">3.3.8</a> <a href="#CONNECT">CONNECT</a></li> 595 <li><a href="#rfc.section.3.2">3.2</a> <a href="#method.definitions">Method Definitions</a><ul> 596 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#OPTIONS">OPTIONS</a></li> 597 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#GET">GET</a></li> 598 <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#HEAD">HEAD</a></li> 599 <li><a href="#rfc.section.3.2.4">3.2.4</a> <a href="#POST">POST</a></li> 600 <li><a href="#rfc.section.3.2.5">3.2.5</a> <a href="#PUT">PUT</a></li> 601 <li><a href="#rfc.section.3.2.6">3.2.6</a> <a href="#DELETE">DELETE</a></li> 602 <li><a href="#rfc.section.3.2.7">3.2.7</a> <a href="#TRACE">TRACE</a></li> 603 <li><a href="#rfc.section.3.2.8">3.2.8</a> <a href="#CONNECT">CONNECT</a></li> 607 604 </ul> 608 605 </li> … … 733 730 </li> 734 731 <li><a href="#rfc.section.11">11.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> 735 <li><a href="#rfc.section.11.1">11.1</a> <a href="#method.registration">Method Registry</a></li> 732 <li><a href="#rfc.section.11.1">11.1</a> <a href="#method.registry">Method Registry</a><ul> 733 <li><a href="#rfc.section.11.1.1">11.1.1</a> <a href="#considerations.for.new.methods">Considerations for New Methods</a></li> 734 <li><a href="#rfc.section.11.1.2">11.1.2</a> <a href="#method.registration">Registrations</a></li> 735 </ul> 736 </li> 736 737 <li><a href="#rfc.section.11.2">11.2</a> <a href="#status.code.registration">Status Code Registry</a></li> 737 738 <li><a href="#rfc.section.11.3">11.3</a> <a href="#header.field.registration">Header Field Registration</a></li> … … 876 877 <td class="left">GET</td> 877 878 <td class="left">Retrieve a current representation of the target resource.</td> 878 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3. 3.2</a></td>879 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.2.2</a></td> 879 880 </tr> 880 881 <tr> 881 882 <td class="left">HEAD</td> 882 883 <td class="left">Same as GET, but do not include a message body in the response.</td> 883 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3. 3.3</a></td>884 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.2.3</a></td> 884 885 </tr> 885 886 <tr> 886 887 <td class="left">POST</td> 887 888 <td class="left">Perform resource-specific processing on the request payload.</td> 888 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3. 3.4</a></td>889 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.2.4</a></td> 889 890 </tr> 890 891 <tr> 891 892 <td class="left">PUT</td> 892 893 <td class="left">Replace all current representations of the target resource with the request payload.</td> 893 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3. 3.5</a></td>894 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.2.5</a></td> 894 895 </tr> 895 896 <tr> 896 897 <td class="left">DELETE</td> 897 898 <td class="left">Remove all current representations of the target resource.</td> 898 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3. 3.6</a></td>899 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.2.6</a></td> 899 900 </tr> 900 901 <tr> 901 902 <td class="left">CONNECT</td> 902 903 <td class="left">Establish a tunnel to the server identified by the target resource.</td> 903 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3. 3.8</a></td>904 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.2.8</a></td> 904 905 </tr> 905 906 <tr> 906 907 <td class="left">OPTIONS</td> 907 908 <td class="left">Describe the communication options for the target resource.</td> 908 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3. 3.1</a></td>909 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.2.1</a></td> 909 910 </tr> 910 911 <tr> 911 912 <td class="left">TRACE</td> 912 913 <td class="left">Perform a message loop-back test along the path to the target resource.</td> 913 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3. 3.7</a></td>914 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.2.7</a></td> 914 915 </tr> 915 916 </tbody> 916 917 </table> 917 918 </div> 918 <p id="rfc.section.3.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. If one of the above methods is implemented by a server, the server <em class="bcp14">MUST</em> implement that method according to the semantics defined for it in <a href="#method.definitions" title="Method Definitions">Section 3.3</a>. 919 </p> 920 <p id="rfc.section.3.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP. New methods <em class="bcp14">SHOULD</em> be registered within the IANA registry, as defined in <a href="#method.registry" title="Method Registry">Section 3.2</a>. 919 <p id="rfc.section.3.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 3.2</a>. 920 </p> 921 <p id="rfc.section.3.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and registered within the HTTP 922 Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 11.1</a>. 921 923 </p> 922 924 <p id="rfc.section.3.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 10.5</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or … … 927 929 <div id="rfc.iref.s.1"></div> 928 930 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 929 <p id="rfc.section.3.1.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the user does not request, and does not expect, any state change930 on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method931 is not expected to cause any harm, loss of property, or unusual burden on the origin server.931 <p id="rfc.section.3.1.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state 932 change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe 933 method is not expected to cause any harm, loss of property, or unusual burden on the origin server. 932 934 </p> 933 935 <p id="rfc.section.3.1.1.p.2">This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, not 934 entirely read-only, or which causes side-effects while invoking a safe method. In fact, some dynamic resources might consider 935 that a feature. What is important, however, is that the user did not request that additional behavior and cannot be held accountable 936 for it. For example, most servers append request information to access log files at the completion of every response, regardless 937 of the method, and that is considered safe even though the log storage might become full and crash the server. 936 entirely read-only, or which causes side-effects while invoking a safe method. What is important, however, is that the client 937 did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information 938 to access log files at the completion of every response, regardless of the method, and that is considered safe even though 939 the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on 940 the Web will often have the side-effect of charging an advertising account. 938 941 </p> 939 942 <p id="rfc.section.3.1.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p> 940 <p id="rfc.section.3.1.1.p.4">A user agent <em class="bcp14">SHOULD</em> distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware 941 of an unsafe action before it is requested. A user agent <em class="bcp14">SHOULD NOT</em> make requests using unsafe methods as an automated result of the user selecting a safe action, unless the instruction for 942 making the unsafe request came from the same origin server as the request target. 943 </p> 944 <p id="rfc.section.3.1.1.p.5">When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, 943 <p id="rfc.section.3.1.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache 944 performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply 945 appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content. 946 </p> 947 <p id="rfc.section.3.1.1.p.5">A user agent <em class="bcp14">SHOULD</em> distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware 948 of an unsafe action before it is requested. 949 </p> 950 <p id="rfc.section.3.1.1.p.6">When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, 945 951 it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, 946 it is common for HTML form-based content editing software to use actions within query parameters, such as "page?do=delete".947 If thepurpose of such a resource is to perform an unsafe action, then the resource <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate948 side-effects when automated processes perform a GET on every URI reference , which often occurs for the sake of link maintenance,949 pre-fetching, or building a search index.952 it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the 953 purpose of such a resource is to perform an unsafe action, then the resource <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate 954 side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, 955 building a search index, etc. 950 956 </p> 951 957 <div id="rfc.iref.i.1"></div> 952 958 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 953 <p id="rfc.section.3.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect 954 of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. 955 It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state 956 due to multiple requests for the purpose of tracking those requests, versioning of results, etc. 957 </p> 958 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> 959 <p id="rfc.section.3.2.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p> 960 <p id="rfc.section.3.2.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 961 </p> 962 <ul> 963 <li>Method Name (see <a href="#methods" title="Request Methods">Section 3</a>) 964 </li> 965 <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>) 966 </li> 967 <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>) 968 </li> 969 <li>Pointer to specification text</li> 970 </ul> 971 <p id="rfc.section.3.2.p.3">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 972 </p> 973 <p id="rfc.section.3.2.p.4">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>>. 974 </p> 975 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3> 976 <p id="rfc.section.3.2.1.p.1">When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, 977 and currently defined methods are inadequate, it might be appropriate to register a new method. 978 </p> 979 <p id="rfc.section.3.2.1.p.2">HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type" 980 of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific 981 to a single application, so that this is clear. 982 </p> 983 <p id="rfc.section.3.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message 984 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 985 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 986 </p> 987 <p id="rfc.section.3.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 3.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular under what conditions a cache can store the response, and under what conditions such a stored response can 988 be used to satisfy a subsequent request. 989 </p> 990 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> 991 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> 959 <p id="rfc.section.3.1.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request 960 methods are idempotent. 961 </p> 962 <p id="rfc.section.3.1.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free 963 to log each request separately, retain a revision control history, or implement other non-idempotent side-effects for each 964 idempotent request. 965 </p> 966 <p id="rfc.section.3.1.2.p.3">Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before 967 the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection 968 is closed before any response is received, then it can establish a new connection and retry the request because it knows that 969 repeating the request will have the same effect even if the original request succeeded. Note, however, that repeated failures 970 would indicate a problem within the server. 971 </p> 972 <div id="rfc.iref.c.2"></div> 973 <h3 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a> <a id="cacheable.methods" href="#cacheable.methods">Cacheable Methods</a></h3> 974 <p id="rfc.section.3.1.3.p.1">Request methods are considered "<dfn id="cacheable">cacheable</dfn>" if it is possible and useful to answer a current client request with a stored response from a prior request. GET and HEAD 975 are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are also cacheable, 976 though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses 977 are defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 978 </p> 979 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> 980 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> 992 981 <div id="rfc.iref.o.1"></div> 993 982 <div id="rfc.iref.m.1"></div> 994 <p id="rfc.section.3. 3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified983 <p id="rfc.section.3.2.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 995 984 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 996 985 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 997 986 </p> 998 <p id="rfc.section.3. 3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>999 <p id="rfc.section.3. 3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS987 <p id="rfc.section.3.2.1.p.2">Responses to the OPTIONS method are not cacheable.</p> 988 <p id="rfc.section.3.2.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS 1000 989 body to make more detailed queries on the server. 1001 990 </p> 1002 <p id="rfc.section.3. 3.1.p.4">If 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.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.991 <p id="rfc.section.3.2.1.p.4">If 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.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1003 992 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1004 993 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1005 994 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1006 995 </p> 1007 <p id="rfc.section.3. 3.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating996 <p id="rfc.section.3.2.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 1008 997 with that resource. 1009 998 </p> 1010 <p id="rfc.section.3. 3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,999 <p id="rfc.section.3.2.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 1011 1000 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0". 1012 1001 </p> 1013 <p id="rfc.section.3. 3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.1014 </p> 1015 <h3 id="rfc.section.3. 3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="GET" href="#GET">GET</a></h3>1002 <p id="rfc.section.3.2.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1003 </p> 1004 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="GET" href="#GET">GET</a></h3> 1016 1005 <div id="rfc.iref.g.2"></div> 1017 1006 <div id="rfc.iref.m.2"></div> 1018 <p id="rfc.section.3. 3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>1019 <p id="rfc.section.3. 3.2.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation1007 <p id="rfc.section.3.2.2.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1008 <p id="rfc.section.3.2.2.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 1020 1009 in the response and not the source text of the process, unless that text happens to be the output of the process. 1021 1010 </p> 1022 <p id="rfc.section.3. 3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional1011 <p id="rfc.section.3.2.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional 1023 1012 header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations 1024 1013 to be refreshed without requiring multiple requests or transferring data already held by the client. 1025 1014 </p> 1026 <p id="rfc.section.3. 3.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations1015 <p id="rfc.section.3.2.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 1027 1016 to be completed without transferring data already held by the client. 1028 1017 </p> 1029 <p id="rfc.section.3. 3.2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations1018 <p id="rfc.section.3.2.2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations 1030 1019 to reject the request. 1031 1020 </p> 1032 <p id="rfc.section.3. 3.2.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1033 </p> 1034 <p id="rfc.section.3. 3.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms.1035 </p> 1036 <h3 id="rfc.section.3. 3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="HEAD" href="#HEAD">HEAD</a></h3>1021 <p id="rfc.section.3.2.2.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1022 </p> 1023 <p id="rfc.section.3.2.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms. 1024 </p> 1025 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1037 1026 <div id="rfc.iref.h.1"></div> 1038 1027 <div id="rfc.iref.m.3"></div> 1039 <p id="rfc.section.3. 3.3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1028 <p id="rfc.section.3.2.3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1040 1029 representation implied by the request without transferring the representation body. This method is often used for testing 1041 1030 hypertext links for validity, accessibility, and recent modification. 1042 1031 </p> 1043 <p id="rfc.section.3. 3.3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1044 </p> 1045 <p id="rfc.section.3. 3.3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations1032 <p id="rfc.section.3.2.3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1033 </p> 1034 <p id="rfc.section.3.2.3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations 1046 1035 to reject the request. 1047 1036 </p> 1048 1037 <div id="rfc.iref.p.1"></div> 1049 1038 <div id="rfc.iref.m.4"></div> 1050 <h3 id="rfc.section.3. 3.4"><a href="#rfc.section.3.3.4">3.3.4</a> <a id="POST" href="#POST">POST</a></h3>1051 <p id="rfc.section.3. 3.4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed1039 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="POST" href="#POST">POST</a></h3> 1040 <p id="rfc.section.3.2.4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1052 1041 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1053 1042 </p> … … 1058 1047 <li>Extending a database through an append operation.</li> 1059 1048 </ul> 1060 <p id="rfc.section.3. 3.4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request1049 <p id="rfc.section.3.2.4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request 1061 1050 URI. 1062 1051 </p> 1063 <p id="rfc.section.3. 3.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes1052 <p id="rfc.section.3.2.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes 1064 1053 the result. 1065 1054 </p> 1066 <p id="rfc.section.3. 3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.13</a>).1067 </p> 1068 <p id="rfc.section.3. 3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1069 </p> 1070 <p id="rfc.section.3. 3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.1071 </p> 1072 <h3 id="rfc.section.3. 3.5"><a href="#rfc.section.3.3.5">3.3.5</a> <a id="PUT" href="#PUT">PUT</a></h3>1055 <p id="rfc.section.3.2.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.13</a>). 1056 </p> 1057 <p id="rfc.section.3.2.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1058 </p> 1059 <p id="rfc.section.3.2.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource. 1060 </p> 1061 <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="PUT" href="#PUT">PUT</a></h3> 1073 1062 <div id="rfc.iref.p.2"></div> 1074 1063 <div id="rfc.iref.m.5"></div> 1075 <p id="rfc.section.3. 3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation1064 <p id="rfc.section.3.2.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1076 1065 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1077 1066 that same target resource will result in an equivalent representation being returned 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 … … 1080 1069 by the origin server. 1081 1070 </p> 1082 <p id="rfc.section.3. 3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance1071 <p id="rfc.section.3.2.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance 1083 1072 with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1084 1073 </p> 1085 <p id="rfc.section.3. 3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).1086 </p> 1087 <p id="rfc.section.3. 3.5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot1074 <p id="rfc.section.3.2.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). 1075 </p> 1076 <p id="rfc.section.3.2.5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot 1088 1077 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1089 1078 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent … … 1091 1080 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values. 1092 1081 </p> 1093 <p id="rfc.section.3. 3.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:1082 <p id="rfc.section.3.2.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: 1094 1083 </p> 1095 1084 <ol class="la"> … … 1102 1091 </li> 1103 1092 </ol> 1104 <p id="rfc.section.3. 3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent1093 <p id="rfc.section.3.2.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent 1105 1094 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 1106 1095 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how … … 1109 1098 the server. 1110 1099 </p> 1111 <p id="rfc.section.3. 3.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.1100 <p id="rfc.section.3.2.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. 1112 1101 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 1113 1102 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT … … 1115 1104 and visible to intermediaries, even though the exact effect is only known by the origin server. 1116 1105 </p> 1117 <p id="rfc.section.3. 3.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that1106 <p id="rfc.section.3.2.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that 1118 1107 is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to 1119 1108 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 1120 1109 to a different URI, then the origin server <em class="bcp14">MUST</em> send a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 1121 1110 </p> 1122 <p id="rfc.section.3. 3.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)1111 <p id="rfc.section.3.2.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) 1123 1112 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 1124 1113 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new … … 1126 1115 the related resources. 1127 1116 </p> 1128 <p id="rfc.section.3. 3.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full1117 <p id="rfc.section.3.2.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full 1129 1118 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1130 1119 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for 1131 1120 example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). 1132 1121 </p> 1133 <p id="rfc.section.3. 3.5.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses1122 <p id="rfc.section.3.2.5.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses 1134 1123 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1135 1124 </p> 1136 <h3 id="rfc.section.3. 3.6"><a href="#rfc.section.3.3.6">3.3.6</a> <a id="DELETE" href="#DELETE">DELETE</a></h3>1125 <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1137 1126 <div id="rfc.iref.d.1"></div> 1138 1127 <div id="rfc.iref.m.6"></div> 1139 <p id="rfc.section.3. 3.6.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation1128 <p id="rfc.section.3.2.6.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1140 1129 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1141 1130 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 1142 1131 location. 1143 1132 </p> 1144 <p id="rfc.section.3. 3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.1145 </p> 1146 <p id="rfc.section.3. 3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing1133 <p id="rfc.section.3.2.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation. 1134 </p> 1135 <p id="rfc.section.3.2.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing 1147 1136 implementations to reject the request. 1148 1137 </p> 1149 <p id="rfc.section.3. 3.6.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses1138 <p id="rfc.section.3.2.6.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1150 1139 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1151 1140 </p> 1152 <h3 id="rfc.section.3. 3.7"><a href="#rfc.section.3.3.7">3.3.7</a> <a id="TRACE" href="#TRACE">TRACE</a></h3>1141 <h3 id="rfc.section.3.2.7"><a href="#rfc.section.3.2.7">3.2.7</a> <a id="TRACE" href="#TRACE">TRACE</a></h3> 1153 1142 <div id="rfc.iref.t.1"></div> 1154 1143 <div id="rfc.iref.m.7"></div> 1155 <p id="rfc.section.3. 3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.1156 </p> 1157 <p id="rfc.section.3. 3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing1158 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding1144 <p id="rfc.section.3.2.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1145 </p> 1146 <p id="rfc.section.3.2.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1147 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1159 1148 messages in an infinite loop. 1160 1149 </p> 1161 <p id="rfc.section.3. 3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1162 </p> 1163 <div id="rfc.iref.c. 2"></div>1150 <p id="rfc.section.3.2.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1151 </p> 1152 <div id="rfc.iref.c.3"></div> 1164 1153 <div id="rfc.iref.m.8"></div> 1165 <h3 id="rfc.section.3. 3.8"><a href="#rfc.section.3.3.8">3.3.8</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3>1166 <p id="rfc.section.3. 3.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict1154 <h3 id="rfc.section.3.2.8"><a href="#rfc.section.3.2.8">3.2.8</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1155 <p id="rfc.section.3.2.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1167 1156 its behavior to blind forwarding of packets until the connection is closed. 1168 1157 </p> 1169 <p id="rfc.section.3. 3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1158 <p id="rfc.section.3.2.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1170 1159 For example, 1171 1160 </p> … … 1173 1162 Host: server.example.com:80 1174 1163 1175 </pre><p id="rfc.section.3. 3.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has1164 </pre><p id="rfc.section.3.2.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has 1176 1165 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1177 1166 after the blank line that concludes the successful response's header block. 1178 1167 </p> 1179 <p id="rfc.section.3. 3.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.1180 </p> 1181 <p id="rfc.section.3. 3.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains1168 <p id="rfc.section.3.2.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1169 </p> 1170 <p id="rfc.section.3.2.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1182 1171 governed by HTTP. 1183 1172 </p> 1184 <p id="rfc.section.3. 3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>1173 <p id="rfc.section.3.2.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1185 1174 <div id="rfc.figure.u.3"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1186 1175 Host: server.example.com:80 1187 1176 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1188 1177 1189 </pre><p id="rfc.section.3. 3.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations1178 </pre><p id="rfc.section.3.2.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 1190 1179 to reject the request. 1191 1180 </p> 1192 <p id="rfc.section.3. 3.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded1181 <p id="rfc.section.3.2.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1193 1182 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1194 1183 </p> 1195 <p id="rfc.section.3. 3.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,1184 <p id="rfc.section.3.2.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, 1196 1185 the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority. 1197 1186 </p> 1198 <p id="rfc.section.3. 3.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to1187 <p id="rfc.section.3.2.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1199 1188 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1200 1189 peer undelivered, that data will be discarded. 1201 1190 </p> 1202 <p id="rfc.section.3. 3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.1191 <p id="rfc.section.3.2.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1203 1192 </p> 1204 1193 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 1205 1194 <p id="rfc.section.4.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 1206 or about the connection itself (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.1 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> for a general definition of their syntax.1195 or about the connection itself (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.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> for a general definition of their syntax. 1207 1196 </p> 1208 1197 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request.fields" href="#request.fields">Request-modifier Header Fields</a></h2> … … 1216 1205 with "X-" if they are to be registered (either immediately or in the future). 1217 1206 </p> 1218 <p id="rfc.section.4.5.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.1 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters1207 <p id="rfc.section.4.5.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.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 1219 1208 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>. 1220 1209 </p> 1221 1210 <p id="rfc.section.4.5.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 1222 1211 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 1223 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).1212 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 1224 1213 </p> 1225 1214 <p id="rfc.section.4.5.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 … … 1239 1228 <ul> 1240 1229 <li> 1241 <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.1 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).1230 <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.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 1242 1231 </p> 1243 1232 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 1255 1244 </li> 1256 1245 <li> 1257 <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.1 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).1246 <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.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 1258 1247 </p> 1259 1248 </li> … … 1266 1255 </li> 1267 1256 <li> 1268 <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.1 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).1257 <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.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 1269 1258 </p> 1270 1259 </li> … … 1317 1306 <tr> 1318 1307 <td class="left">Host</td> 1319 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td>1308 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td> 1320 1309 </tr> 1321 1310 <tr> … … 1357 1346 <tr> 1358 1347 <td class="left">TE</td> 1359 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td>1348 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td> 1360 1349 </tr> 1361 1350 <tr> … … 1368 1357 <h2 id="rfc.section.4.7"><a href="#rfc.section.4.7">4.7</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1369 1358 <p id="rfc.section.4.7.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1370 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. 20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).1359 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.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 1371 1360 </p> 1372 1361 <div id="rfc.table.u.2"> … … 1676 1665 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> 1677 1666 <p id="rfc.section.5.2.p.1">The HTTP Status Code Registry defines the name space for the status-code token in the status-line of an HTTP response.</p> 1678 <p id="rfc.section.5.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226. 2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).1667 <p id="rfc.section.5.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 1679 1668 </p> 1680 1669 <p id="rfc.section.5.2.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. … … 1698 1687 </p> 1699 1688 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> 1700 <div id="rfc.iref.2 0"></div>1689 <div id="rfc.iref.21"></div> 1701 1690 <div id="rfc.iref.s.2"></div> 1702 1691 <p id="rfc.section.5.3.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields, … … 1711 1700 a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).) 1712 1701 </p> 1713 <div id="rfc.iref.2 1"></div>1702 <div id="rfc.iref.22"></div> 1714 1703 <div id="rfc.iref.s.3"></div> 1715 1704 <h3 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> 1716 1705 <p id="rfc.section.5.3.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1717 1706 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1718 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1719 </p> 1720 <div id="rfc.iref.2 2"></div>1707 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1708 </p> 1709 <div id="rfc.iref.23"></div> 1721 1710 <div id="rfc.iref.s.4"></div> 1722 1711 <h3 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1723 <p id="rfc.section.5.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1712 <p id="rfc.section.5.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1724 1713 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1725 1714 </p> … … 1729 1718 </p> 1730 1719 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> 1731 <div id="rfc.iref.2 3"></div>1720 <div id="rfc.iref.24"></div> 1732 1721 <div id="rfc.iref.s.5"></div> 1733 1722 <p id="rfc.section.5.4.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> 1734 <div id="rfc.iref.2 4"></div>1723 <div id="rfc.iref.25"></div> 1735 1724 <div id="rfc.iref.s.6"></div> 1736 1725 <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> … … 1748 1737 <p id="rfc.section.5.4.1.p.2">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.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. 1749 1738 </p> 1750 <div id="rfc.iref.2 5"></div>1739 <div id="rfc.iref.26"></div> 1751 1740 <div id="rfc.iref.s.7"></div> 1752 1741 <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> … … 1761 1750 the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1762 1751 </p> 1763 <div id="rfc.iref.2 6"></div>1752 <div id="rfc.iref.27"></div> 1764 1753 <div id="rfc.iref.s.8"></div> 1765 1754 <h3 id="rfc.section.5.4.3"><a href="#rfc.section.5.4.3">5.4.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> … … 1773 1762 user can expect the request to be fulfilled. 1774 1763 </p> 1775 <div id="rfc.iref.2 7"></div>1764 <div id="rfc.iref.28"></div> 1776 1765 <div id="rfc.iref.s.9"></div> 1777 1766 <h3 id="rfc.section.5.4.4"><a href="#rfc.section.5.4.4">5.4.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1778 <p id="rfc.section.5.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1767 <p id="rfc.section.5.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1779 1768 </p> 1780 1769 <p id="rfc.section.5.4.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code … … 1783 1772 <p id="rfc.section.5.4.4.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.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1784 1773 </p> 1785 <div id="rfc.iref.2 8"></div>1774 <div id="rfc.iref.29"></div> 1786 1775 <div id="rfc.iref.s.10"></div> 1787 1776 <h3 id="rfc.section.5.4.5"><a href="#rfc.section.5.4.5">5.4.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> … … 1804 1793 <p id="rfc.section.5.4.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. 1805 1794 </p> 1806 <div id="rfc.iref. 29"></div>1795 <div id="rfc.iref.30"></div> 1807 1796 <div id="rfc.iref.s.11"></div> 1808 1797 <h3 id="rfc.section.5.4.6"><a href="#rfc.section.5.4.6">5.4.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> … … 1811 1800 another input action. 1812 1801 </p> 1813 <p id="rfc.section.5.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>.1802 <p id="rfc.section.5.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. 1814 1803 </p> 1815 1804 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> 1816 <div id="rfc.iref.3 0"></div>1805 <div id="rfc.iref.31"></div> 1817 1806 <div id="rfc.iref.s.12"></div> 1818 1807 <p id="rfc.section.5.5.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. … … 1860 1849 </p> 1861 1850 </div> 1862 <div id="rfc.iref.3 1"></div>1851 <div id="rfc.iref.32"></div> 1863 1852 <div id="rfc.iref.s.13"></div> 1864 1853 <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> … … 1875 1864 <p id="rfc.section.5.5.1.p.4">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.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1876 1865 </p> 1877 <div id="rfc.iref.3 2"></div>1866 <div id="rfc.iref.33"></div> 1878 1867 <div id="rfc.iref.s.14"></div> 1879 1868 <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> … … 1889 1878 </p> 1890 1879 </div> 1891 <div id="rfc.iref.3 3"></div>1880 <div id="rfc.iref.34"></div> 1892 1881 <div id="rfc.iref.s.15"></div> 1893 1882 <h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> … … 1900 1889 </p> 1901 1890 </div> 1902 <div id="rfc.iref.3 4"></div>1891 <div id="rfc.iref.35"></div> 1903 1892 <div id="rfc.iref.s.16"></div> 1904 1893 <h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> … … 1921 1910 <p id="rfc.section.5.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI. 1922 1911 </p> 1923 <div id="rfc.iref.3 5"></div>1912 <div id="rfc.iref.36"></div> 1924 1913 <div id="rfc.iref.s.17"></div> 1925 1914 <h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> 1926 1915 <p id="rfc.section.5.5.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix C</a>), and is now deprecated. 1927 1916 </p> 1928 <div id="rfc.iref.3 6"></div>1917 <div id="rfc.iref.37"></div> 1929 1918 <div id="rfc.iref.s.18"></div> 1930 1919 <h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> 1931 1920 <p id="rfc.section.5.5.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> 1932 <div id="rfc.iref.3 7"></div>1921 <div id="rfc.iref.38"></div> 1933 1922 <div id="rfc.iref.s.19"></div> 1934 1923 <h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> … … 1944 1933 </div> 1945 1934 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> 1946 <div id="rfc.iref.3 8"></div>1935 <div id="rfc.iref.39"></div> 1947 1936 <div id="rfc.iref.s.20"></div> 1948 1937 <p id="rfc.section.5.6.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD … … 1950 1939 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. 1951 1940 </p> 1952 <div id="rfc.iref. 39"></div>1941 <div id="rfc.iref.40"></div> 1953 1942 <div id="rfc.iref.s.21"></div> 1954 1943 <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> 1955 1944 <p id="rfc.section.5.6.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p> 1956 <div id="rfc.iref.4 0"></div>1945 <div id="rfc.iref.41"></div> 1957 1946 <div id="rfc.iref.s.22"></div> 1958 1947 <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> 1959 1948 <p id="rfc.section.5.6.2.p.1">This code is reserved for future use.</p> 1960 <div id="rfc.iref.4 1"></div>1949 <div id="rfc.iref.42"></div> 1961 1950 <div id="rfc.iref.s.23"></div> 1962 1951 <h3 id="rfc.section.5.6.3"><a href="#rfc.section.5.6.3">5.6.3</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> … … 1968 1957 (Not Found)</a> <em class="bcp14">MAY</em> be used instead. 1969 1958 </p> 1970 <div id="rfc.iref.4 2"></div>1959 <div id="rfc.iref.43"></div> 1971 1960 <div id="rfc.iref.s.24"></div> 1972 1961 <h3 id="rfc.section.5.6.4"><a href="#rfc.section.5.6.4">5.6.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> … … 1976 1965 has been refused, or when no other response is applicable. 1977 1966 </p> 1978 <div id="rfc.iref.4 3"></div>1967 <div id="rfc.iref.44"></div> 1979 1968 <div id="rfc.iref.s.25"></div> 1980 1969 <h3 id="rfc.section.5.6.5"><a href="#rfc.section.5.6.5">5.6.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1981 1970 <p id="rfc.section.5.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource. 1982 1971 </p> 1983 <div id="rfc.iref.4 4"></div>1972 <div id="rfc.iref.45"></div> 1984 1973 <div id="rfc.iref.s.26"></div> 1985 1974 <h3 id="rfc.section.5.6.6"><a href="#rfc.section.5.6.6">5.6.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> … … 1999 1988 <p id="rfc.section.5.6.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. 2000 1989 </p> 2001 <div id="rfc.iref.4 5"></div>1990 <div id="rfc.iref.46"></div> 2002 1991 <div id="rfc.iref.s.27"></div> 2003 1992 <h3 id="rfc.section.5.6.7"><a href="#rfc.section.5.6.7">5.6.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> 2004 1993 <p id="rfc.section.5.6.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. 2005 1994 </p> 2006 <div id="rfc.iref.4 6"></div>1995 <div id="rfc.iref.47"></div> 2007 1996 <div id="rfc.iref.s.28"></div> 2008 1997 <h3 id="rfc.section.5.6.8"><a href="#rfc.section.5.6.8">5.6.8</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> … … 2017 2006 contain a list of the differences between the two versions. 2018 2007 </p> 2019 <div id="rfc.iref.4 7"></div>2008 <div id="rfc.iref.48"></div> 2020 2009 <div id="rfc.iref.s.29"></div> 2021 2010 <h3 id="rfc.section.5.6.9"><a href="#rfc.section.5.6.9">5.6.9</a> <a id="status.410" href="#status.410">410 Gone</a></h3> … … 2032 2021 <p id="rfc.section.5.6.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.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 2033 2022 </p> 2034 <div id="rfc.iref.4 8"></div>2023 <div id="rfc.iref.49"></div> 2035 2024 <div id="rfc.iref.s.30"></div> 2036 2025 <h3 id="rfc.section.5.6.10"><a href="#rfc.section.5.6.10">5.6.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> … … 2038 2027 message. 2039 2028 </p> 2040 <div id="rfc.iref. 49"></div>2029 <div id="rfc.iref.50"></div> 2041 2030 <div id="rfc.iref.s.31"></div> 2042 2031 <h3 id="rfc.section.5.6.11"><a href="#rfc.section.5.6.11">5.6.11</a> <a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3> … … 2046 2035 <p id="rfc.section.5.6.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. 2047 2036 </p> 2048 <div id="rfc.iref.5 0"></div>2037 <div id="rfc.iref.51"></div> 2049 2038 <div id="rfc.iref.s.32"></div> 2050 2039 <h3 id="rfc.section.5.6.12"><a href="#rfc.section.5.6.12">5.6.12</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> … … 2055 2044 in some servers using fixed-length buffers for reading or manipulating the request-target. 2056 2045 </p> 2057 <div id="rfc.iref.5 1"></div>2046 <div id="rfc.iref.52"></div> 2058 2047 <div id="rfc.iref.s.33"></div> 2059 2048 <h3 id="rfc.section.5.6.13"><a href="#rfc.section.5.6.13">5.6.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> … … 2061 2050 on the target resource. 2062 2051 </p> 2063 <div id="rfc.iref.5 2"></div>2052 <div id="rfc.iref.53"></div> 2064 2053 <div id="rfc.iref.s.34"></div> 2065 2054 <h3 id="rfc.section.5.6.14"><a href="#rfc.section.5.6.14">5.6.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> … … 2067 2056 not be met by the next-hop server. 2068 2057 </p> 2069 <div id="rfc.iref.5 3"></div>2058 <div id="rfc.iref.54"></div> 2070 2059 <div id="rfc.iref.s.35"></div> 2071 2060 <h3 id="rfc.section.5.6.15"><a href="#rfc.section.5.6.15">5.6.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2072 <p id="rfc.section.5.6.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.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) specifying the required protocols.2061 <p id="rfc.section.5.6.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.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) specifying the required protocols. 2073 2062 </p> 2074 2063 <div id="rfc.figure.u.5"></div> … … 2084 2073 </p> 2085 2074 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> 2086 <div id="rfc.iref.5 4"></div>2075 <div id="rfc.iref.55"></div> 2087 2076 <div id="rfc.iref.s.36"></div> 2088 2077 <p id="rfc.section.5.7.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable … … 2090 2079 User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. 2091 2080 </p> 2092 <div id="rfc.iref.5 5"></div>2081 <div id="rfc.iref.56"></div> 2093 2082 <div id="rfc.iref.s.37"></div> 2094 2083 <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> 2095 2084 <p id="rfc.section.5.7.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> 2096 <div id="rfc.iref.5 6"></div>2085 <div id="rfc.iref.57"></div> 2097 2086 <div id="rfc.iref.s.38"></div> 2098 2087 <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3> … … 2100 2089 does not recognize the request method and is not capable of supporting it for any resource. 2101 2090 </p> 2102 <div id="rfc.iref.5 7"></div>2091 <div id="rfc.iref.58"></div> 2103 2092 <div id="rfc.iref.s.39"></div> 2104 2093 <h3 id="rfc.section.5.7.3"><a href="#rfc.section.5.7.3">5.7.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3> … … 2106 2095 to fulfill the request. 2107 2096 </p> 2108 <div id="rfc.iref.5 8"></div>2097 <div id="rfc.iref.59"></div> 2109 2098 <div id="rfc.iref.s.40"></div> 2110 2099 <h3 id="rfc.section.5.7.4"><a href="#rfc.section.5.7.4">5.7.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> … … 2119 2108 </p> 2120 2109 </div> 2121 <div id="rfc.iref. 59"></div>2110 <div id="rfc.iref.60"></div> 2122 2111 <div id="rfc.iref.s.41"></div> 2123 2112 <h3 id="rfc.section.5.7.5"><a href="#rfc.section.5.7.5">5.7.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> … … 2130 2119 </p> 2131 2120 </div> 2132 <div id="rfc.iref.6 0"></div>2121 <div id="rfc.iref.61"></div> 2133 2122 <div id="rfc.iref.s.42"></div> 2134 2123 <h3 id="rfc.section.5.7.6"><a href="#rfc.section.5.7.6">5.7.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> 2135 2124 <p id="rfc.section.5.7.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2136 2125 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2137 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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.2126 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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. 2138 2127 </p> 2139 2128 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 2261 2250 mechanism will be required to remove the encoding. 2262 2251 </p> 2263 <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c. 3"></span><span id="rfc.iref.c.4"></span>2252 <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.4"></span><span id="rfc.iref.c.5"></span> 2264 2253 </p> 2265 2254 <ul class="empty"> 2266 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>.2267 </li> 2268 </ul> 2269 <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c. 5"></span>2255 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. 2256 </li> 2257 </ul> 2258 <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.6"></span> 2270 2259 </p> 2271 2260 <ul class="empty"> 2272 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>.2273 </li> 2274 </ul> 2275 <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c. 6"></span>2261 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. 2262 </li> 2263 </ul> 2264 <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.7"></span> 2276 2265 </p> 2277 2266 <ul class="empty"> 2278 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>.2267 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. 2279 2268 </li> 2280 2269 </ul> … … 2288 2277 <li>Pointer to specification text</li> 2289 2278 </ul> 2290 <p id="rfc.section.6.4.1.p.3">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. 30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).2291 </p> 2292 <p id="rfc.section.6.4.1.p.4">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.2279 <p id="rfc.section.6.4.1.p.3">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.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 2280 </p> 2281 <p id="rfc.section.6.4.1.p.4">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.2"><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. 2293 2282 </p> 2294 2283 <p id="rfc.section.6.4.1.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. … … 2387 2376 <tr> 2388 2377 <td class="left">Content-Length</td> 2389 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td>2378 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a></td> 2390 2379 </tr> 2391 2380 <tr> … … 2397 2386 </div> 2398 2387 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 2399 <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.2388 <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 2400 2389 </p> 2401 2390 <div id="rfc.iref.r.1"></div> … … 2416 2405 in an HTTP message, it is referred to as the payload of the message. 2417 2406 </p> 2418 <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.2407 <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 2419 2408 </p> 2420 2409 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 2421 2410 <p id="rfc.section.8.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 2422 2411 <p id="rfc.section.8.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 2423 <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following2412 <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 2424 2413 rules are used (with the first applicable one being selected): 2425 2414 </p> … … 2835 2824 to the generic message handling rules. 2836 2825 </p> 2837 <div id="rfc.iref.c. 7"></div>2826 <div id="rfc.iref.c.8"></div> 2838 2827 <div id="rfc.iref.h.7"></div> 2839 2828 <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> … … 2863 2852 <p id="rfc.section.10.6.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type). 2864 2853 </p> 2865 <div id="rfc.iref.c. 8"></div>2854 <div id="rfc.iref.c.9"></div> 2866 2855 <div id="rfc.iref.h.8"></div> 2867 2856 <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> … … 2889 2878 <p id="rfc.section.10.7.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 2890 2879 </p> 2891 <div id="rfc.iref.c. 9"></div>2880 <div id="rfc.iref.c.10"></div> 2892 2881 <div id="rfc.iref.h.9"></div> 2893 2882 <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> … … 2896 2885 </p> 2897 2886 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a> 2898 </pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for 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.3 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME2887 </pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for 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.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 2899 2888 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 2900 2889 </p> … … 2929 2918 </p> 2930 2919 <p id="rfc.section.10.8.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 2931 <div id="rfc.iref.c.1 0"></div>2920 <div id="rfc.iref.c.11"></div> 2932 2921 <div id="rfc.iref.h.10"></div> 2933 2922 <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> … … 2987 2976 </p> 2988 2977 <p id="rfc.section.10.11.p.4">The only expectation defined by this specification is:</p> 2989 <p id="rfc.section.10.11.p.5"><span id="rfc.iref.14 1"></span><span id="rfc.iref.e.2"></span> 100-continue2978 <p id="rfc.section.10.11.p.5"><span id="rfc.iref.142"></span><span id="rfc.iref.e.2"></span> 100-continue 2990 2979 </p> 2991 2980 <ul class="empty"> 2992 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. It does not support any expect-params.2981 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. It does not support any expect-params. 2993 2982 </li> 2994 2983 </ul> … … 3053 3042 <div id="rfc.iref.h.15"></div> 3054 3043 <h2 id="rfc.section.10.14"><a href="#rfc.section.10.14">10.14</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 3055 <p id="rfc.section.10.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 3. 3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 3.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting3044 <p id="rfc.section.10.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 3.2.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 3.2.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 3056 3045 to trace a request which appears to be failing or looping mid-chain. 3057 3046 </p> … … 3101 3090 <h2 id="rfc.section.10.17"><a href="#rfc.section.10.17">10.17</a> <a id="header.server" href="#header.server">Server</a></h2> 3102 3091 <p id="rfc.section.10.17.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 3103 <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for3092 <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 3104 3093 identifying the application. 3105 3094 </p> … … 3107 3096 </pre><p id="rfc.section.10.17.p.4">Example:</p> 3108 3097 <div id="rfc.figure.u.59"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 3109 </pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.3 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>).3098 </pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). 3110 3099 </p> 3111 3100 <div class="note" id="rfc.section.10.17.p.7"> … … 3123 3112 user agent limitations. 3124 3113 </p> 3125 <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance3114 <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 3126 3115 for identifying the application. 3127 3116 </p> … … 3138 3127 <div id="rfc.figure.u.61"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 3139 3128 </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 3140 <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> 3141 <p id="rfc.section.11.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 3.2</a> of this document. 3142 </p> 3143 <p id="rfc.section.11.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 3129 <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> 3130 <p id="rfc.section.11.1.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p> 3131 <p id="rfc.section.11.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 3132 </p> 3133 <ul> 3134 <li>Method Name (see <a href="#methods" title="Request Methods">Section 3</a>) 3135 </li> 3136 <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>) 3137 </li> 3138 <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>) 3139 </li> 3140 <li>Pointer to specification text</li> 3141 </ul> 3142 <p id="rfc.section.11.1.p.3">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 3143 </p> 3144 <p id="rfc.section.11.1.p.4">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>>. 3145 </p> 3146 <h3 id="rfc.section.11.1.1"><a href="#rfc.section.11.1.1">11.1.1</a> <a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3> 3147 <p id="rfc.section.11.1.1.p.1">Standardized HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media 3148 type, kind of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't 3149 specific to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3150 </p> 3151 <p id="rfc.section.11.1.1.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing 3152 algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods 3153 can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain 3154 a Content-Length header field with a value of "0". 3155 </p> 3156 <p id="rfc.section.11.1.1.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 3.1.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 3.1.2</a>), or cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section 3.1.3</a>), and what semantics are to be associated with the request body if any is present in the request. If a method is cacheable, 3157 the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy 3158 a subsequent request. 3159 </p> 3160 <h3 id="rfc.section.11.1.2"><a href="#rfc.section.11.1.2">11.1.2</a> <a id="method.registration" href="#method.registration">Registrations</a></h3> 3161 <p id="rfc.section.11.1.2.p.1">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 3144 3162 </p> 3145 3163 <div id="rfc.table.2"> … … 3159 3177 <td class="left">no</td> 3160 3178 <td class="left">no</td> 3161 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 3. 3.8</a>3179 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 3.2.8</a> 3162 3180 </td> 3163 3181 </tr> … … 3166 3184 <td class="left">no</td> 3167 3185 <td class="left">yes</td> 3168 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 3. 3.6</a>3186 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 3.2.6</a> 3169 3187 </td> 3170 3188 </tr> … … 3173 3191 <td class="left">yes</td> 3174 3192 <td class="left">yes</td> 3175 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 3. 3.2</a>3193 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 3.2.2</a> 3176 3194 </td> 3177 3195 </tr> … … 3180 3198 <td class="left">yes</td> 3181 3199 <td class="left">yes</td> 3182 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 3. 3.3</a>3200 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 3.2.3</a> 3183 3201 </td> 3184 3202 </tr> … … 3187 3205 <td class="left">yes</td> 3188 3206 <td class="left">yes</td> 3189 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 3. 3.1</a>3207 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 3.2.1</a> 3190 3208 </td> 3191 3209 </tr> … … 3194 3212 <td class="left">no</td> 3195 3213 <td class="left">no</td> 3196 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 3. 3.4</a>3214 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 3.2.4</a> 3197 3215 </td> 3198 3216 </tr> … … 3201 3219 <td class="left">no</td> 3202 3220 <td class="left">yes</td> 3203 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 3. 3.5</a>3221 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 3.2.5</a> 3204 3222 </td> 3205 3223 </tr> … … 3208 3226 <td class="left">yes</td> 3209 3227 <td class="left">yes</td> 3210 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 3. 3.7</a>3228 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 3.2.7</a> 3211 3229 </td> 3212 3230 </tr> … … 3679 3697 user. 3680 3698 </p> 3681 <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 3. 3.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used3699 <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 3.2.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 3682 3700 to collect data from the client. 3683 3701 </p> … … 3975 3993 However, this parameter is not part of the MIME standards). 3976 3994 </p> 3977 <div id="rfc.iref.c.1 1"></div>3995 <div id="rfc.iref.c.12"></div> 3978 3996 <div id="rfc.iref.h.21"></div> 3979 3997 <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2> … … 3999 4017 </p> 4000 4018 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 4001 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 3.2</a>)4002 </p> 4003 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 3. 3.4</a>)4004 </p> 4005 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 3. 3.5</a>)4006 </p> 4007 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 3. 3.8</a>)4019 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 11.1</a>) 4020 </p> 4021 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 3.2.4</a>) 4022 </p> 4023 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 3.2.5</a>) 4024 </p> 4025 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 3.2.8</a>) 4008 4026 </p> 4009 4027 <p id="rfc.section.C.p.5">Take over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 5.2</a>) … … 4784 4802 <ul class="ind"> 4785 4803 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4786 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5.1</a>, <a href="#rfc.iref.2 1"><b>5.3.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li>4787 <li>100-continue (expect value) <a href="#rfc.iref.14 1"><b>10.11</b></a></li>4788 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">5.1</a>, <a href="#rfc.iref.2 2"><b>5.3.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li>4789 <li>1xx Informational (status code class) <a href="#rfc.iref.2 0"><b>5.3</b></a></li>4804 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5.1</a>, <a href="#rfc.iref.22"><b>5.3.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> 4805 <li>100-continue (expect value) <a href="#rfc.iref.142"><b>10.11</b></a></li> 4806 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">5.1</a>, <a href="#rfc.iref.23"><b>5.3.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> 4807 <li>1xx Informational (status code class) <a href="#rfc.iref.21"><b>5.3</b></a></li> 4790 4808 </ul> 4791 4809 </li> 4792 4810 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 4793 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">5.1</a>, <a href="#rfc.iref.2 4"><b>5.4.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li>4794 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">5.1</a>, <a href="#rfc.iref.2 5"><b>5.4.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li>4795 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">5.1</a>, <a href="#rfc.iref.2 6"><b>5.4.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li>4796 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">5.1</a>, <a href="#rfc.iref.2 7"><b>5.4.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">C</a></li>4797 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">5.1</a>, <a href="#rfc.iref.2 8"><b>5.4.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li>4798 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">5.1</a>, <a href="#rfc.iref. 29"><b>5.4.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li>4799 <li>2xx Successful (status code class) <a href="#rfc.iref.2 3"><b>5.4</b></a></li>4811 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">5.1</a>, <a href="#rfc.iref.25"><b>5.4.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> 4812 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">5.1</a>, <a href="#rfc.iref.26"><b>5.4.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li> 4813 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">5.1</a>, <a href="#rfc.iref.27"><b>5.4.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> 4814 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">5.1</a>, <a href="#rfc.iref.28"><b>5.4.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">C</a></li> 4815 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">5.1</a>, <a href="#rfc.iref.29"><b>5.4.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> 4816 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">5.1</a>, <a href="#rfc.iref.30"><b>5.4.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> 4817 <li>2xx Successful (status code class) <a href="#rfc.iref.24"><b>5.4</b></a></li> 4800 4818 </ul> 4801 4819 </li> 4802 4820 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 4803 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">5.1</a>, <a href="#rfc.iref.3 1"><b>5.5.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li>4804 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">5.1</a>, <a href="#rfc.iref.3 2"><b>5.5.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">C</a></li>4805 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">5.1</a>, <a href="#rfc.iref.3 3"><b>5.5.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">C</a></li>4806 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">5.1</a>, <a href="#rfc.iref.3 4"><b>5.5.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li>4807 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">5.1</a>, <a href="#rfc.iref.3 5"><b>5.5.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">C</a></li>4808 <li>306 (Unused) (status code) <a href="#rfc.iref.3 6"><b>5.5.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li>4809 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">5.1</a>, <a href="#rfc.iref.3 7"><b>5.5.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">C</a></li>4810 <li>3xx Redirection (status code class) <a href="#rfc.iref.3 0"><b>5.5</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>4821 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">5.1</a>, <a href="#rfc.iref.32"><b>5.5.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> 4822 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">5.1</a>, <a href="#rfc.iref.33"><b>5.5.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">C</a></li> 4823 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">5.1</a>, <a href="#rfc.iref.34"><b>5.5.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">C</a></li> 4824 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">5.1</a>, <a href="#rfc.iref.35"><b>5.5.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> 4825 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">5.1</a>, <a href="#rfc.iref.36"><b>5.5.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">C</a></li> 4826 <li>306 (Unused) (status code) <a href="#rfc.iref.37"><b>5.5.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> 4827 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">5.1</a>, <a href="#rfc.iref.38"><b>5.5.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">C</a></li> 4828 <li>3xx Redirection (status code class) <a href="#rfc.iref.31"><b>5.5</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li> 4811 4829 </ul> 4812 4830 </li> 4813 4831 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 4814 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">5.1</a>, <a href="#rfc.iref. 39"><b>5.6.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li>4815 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">5.1</a>, <a href="#rfc.iref.4 0"><b>5.6.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li>4816 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">5.1</a>, <a href="#rfc.iref.4 1"><b>5.6.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li>4817 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">5.1</a>, <a href="#rfc.iref.4 2"><b>5.6.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li>4818 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">5.1</a>, <a href="#rfc.iref.4 3"><b>5.6.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li>4819 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">5.1</a>, <a href="#rfc.iref.4 4"><b>5.6.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li>4820 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">5.1</a>, <a href="#rfc.iref.4 5"><b>5.6.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li>4821 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">5.1</a>, <a href="#rfc.iref.4 6"><b>5.6.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li>4822 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">5.1</a>, <a href="#rfc.iref.4 7"><b>5.6.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li>4823 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">5.1</a>, <a href="#rfc.iref.4 8"><b>5.6.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li>4824 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">5.1</a>, <a href="#rfc.iref. 49"><b>5.6.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li>4825 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">5.1</a>, <a href="#rfc.iref.5 0"><b>5.6.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li>4826 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">5.1</a>, <a href="#rfc.iref.5 1"><b>5.6.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li>4827 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">5.1</a>, <a href="#rfc.iref.5 2"><b>5.6.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li>4828 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">5.1</a>, <a href="#rfc.iref.5 3"><b>5.6.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">C</a></li>4829 <li>4xx Client Error (status code class) <a href="#rfc.iref.3 8"><b>5.6</b></a></li>4832 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">5.1</a>, <a href="#rfc.iref.40"><b>5.6.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> 4833 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">5.1</a>, <a href="#rfc.iref.41"><b>5.6.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> 4834 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">5.1</a>, <a href="#rfc.iref.42"><b>5.6.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li> 4835 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">5.1</a>, <a href="#rfc.iref.43"><b>5.6.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li> 4836 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">5.1</a>, <a href="#rfc.iref.44"><b>5.6.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> 4837 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">5.1</a>, <a href="#rfc.iref.45"><b>5.6.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> 4838 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">5.1</a>, <a href="#rfc.iref.46"><b>5.6.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> 4839 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">5.1</a>, <a href="#rfc.iref.47"><b>5.6.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> 4840 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">5.1</a>, <a href="#rfc.iref.48"><b>5.6.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li> 4841 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">5.1</a>, <a href="#rfc.iref.49"><b>5.6.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> 4842 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">5.1</a>, <a href="#rfc.iref.50"><b>5.6.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> 4843 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">5.1</a>, <a href="#rfc.iref.51"><b>5.6.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> 4844 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">5.1</a>, <a href="#rfc.iref.52"><b>5.6.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> 4845 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">5.1</a>, <a href="#rfc.iref.53"><b>5.6.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> 4846 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">5.1</a>, <a href="#rfc.iref.54"><b>5.6.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">C</a></li> 4847 <li>4xx Client Error (status code class) <a href="#rfc.iref.39"><b>5.6</b></a></li> 4830 4848 </ul> 4831 4849 </li> 4832 4850 <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> 4833 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">5.1</a>, <a href="#rfc.iref.5 5"><b>5.7.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li>4834 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">5.1</a>, <a href="#rfc.iref.5 6"><b>5.7.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li>4835 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">5.1</a>, <a href="#rfc.iref.5 7"><b>5.7.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li>4836 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">5.1</a>, <a href="#rfc.iref.5 8"><b>5.7.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li>4837 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">5.1</a>, <a href="#rfc.iref. 59"><b>5.7.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li>4838 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">5.1</a>, <a href="#rfc.iref.6 0"><b>5.7.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li>4839 <li>5xx Server Error (status code class) <a href="#rfc.iref.5 4"><b>5.7</b></a></li>4851 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">5.1</a>, <a href="#rfc.iref.56"><b>5.7.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> 4852 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">5.1</a>, <a href="#rfc.iref.57"><b>5.7.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> 4853 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">5.1</a>, <a href="#rfc.iref.58"><b>5.7.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> 4854 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">5.1</a>, <a href="#rfc.iref.59"><b>5.7.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> 4855 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">5.1</a>, <a href="#rfc.iref.60"><b>5.7.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li> 4856 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">5.1</a>, <a href="#rfc.iref.61"><b>5.7.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> 4857 <li>5xx Server Error (status code class) <a href="#rfc.iref.55"><b>5.7</b></a></li> 4840 4858 </ul> 4841 4859 </li> … … 4849 4867 </li> 4850 4868 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 4869 <li>cacheable <a href="#rfc.iref.c.2"><b>3.1.3</b></a></li> 4851 4870 <li>Coding Format 4852 4871 <ul> 4853 <li>compress <a href="#rfc.iref.c. 4">6.4</a></li>4854 <li>deflate <a href="#rfc.iref.c. 5">6.4</a></li>4855 <li>gzip <a href="#rfc.iref.c. 6">6.4</a></li>4872 <li>compress <a href="#rfc.iref.c.5">6.4</a></li> 4873 <li>deflate <a href="#rfc.iref.c.6">6.4</a></li> 4874 <li>gzip <a href="#rfc.iref.c.7">6.4</a></li> 4856 4875 </ul> 4857 4876 </li> 4858 <li>compress (Coding Format) <a href="#rfc.iref.c. 3">6.4</a></li>4859 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c. 2"><b>3.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>4877 <li>compress (Coding Format) <a href="#rfc.iref.c.4">6.4</a></li> 4878 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c.3"><b>3.2.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 4860 4879 <li>content negotiation <a href="#rfc.iref.c.1">1</a></li> 4861 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.c. 7"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li>4862 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.c. 8"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li>4863 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3. 3.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.c.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4864 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.1 1">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>4865 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.c.1 0"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li>4880 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.c.8"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li> 4881 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.c.9"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li> 4882 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3.2.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.c.10"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4883 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.12">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4884 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.c.11"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li> 4866 4885 </ul> 4867 4886 </li> … … 4869 4888 <li>Date header field <a href="#rfc.xref.header.date.1">4.7</a>, <a href="#rfc.iref.d.3"><b>10.10</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li> 4870 4889 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.4</a></li> 4871 <li>DELETE method <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>3. 3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>4890 <li>DELETE method <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>3.2.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li> 4872 4891 <li><em>draft-reschke-http-status-308</em> <a href="#rfc.xref.draft-reschke-http-status-308.1">5.5.7</a>, <a href="#draft-reschke-http-status-308"><b>14.2</b></a></li> 4873 4892 </ul> … … 4887 4906 </li> 4888 4907 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 4889 <li>GET method <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.2"><b>3. 3.2</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>4908 <li>GET method <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.2"><b>3.2.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li> 4890 4909 <li><tt>Grammar</tt> 4891 4910 <ul> … … 4955 4974 </li> 4956 4975 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 4957 <li>HEAD method <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>3. 3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>4976 <li>HEAD method <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>3.2.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li> 4958 4977 <li>Header Fields 4959 4978 <ul> … … 4965 4984 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li> 4966 4985 <li>Content-Language <a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li> 4967 <li>Content-Location <a href="#rfc.xref.header.content-location.1">3. 3.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4986 <li>Content-Location <a href="#rfc.xref.header.content-location.1">3.2.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4968 4987 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4969 4988 <li>Content-Type <a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li> … … 4971 4990 <li>Expect <a href="#rfc.xref.header.expect.1">4.6</a>, <a href="#rfc.xref.header.expect.2">5.6.14</a>, <a href="#rfc.iref.h.12"><b>10.11</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li> 4972 4991 <li>From <a href="#rfc.xref.header.from.1">4.6</a>, <a href="#rfc.iref.h.13"><b>10.12</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> 4973 <li>Location <a href="#rfc.xref.header.location.1">3. 3.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>4974 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3. 3.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>4992 <li>Location <a href="#rfc.xref.header.location.1">3.2.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li> 4993 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3.2.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.2.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 4975 4994 <li>MIME-Version <a href="#rfc.xref.mime-version.1">11.3</a>, <a href="#rfc.iref.h.20"><b>A.1</b></a></li> 4976 4995 <li>Referer <a href="#rfc.xref.header.referer.1">4.6</a>, <a href="#rfc.iref.h.16"><b>10.15</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li> … … 4983 5002 </li> 4984 5003 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 4985 <li> Idempotent Methods <a href="#rfc.iref.i.1"><b>3.1.2</b></a></li>5004 <li>idempotent <a href="#rfc.iref.i.1"><b>3.1.2</b></a></li> 4986 5005 </ul> 4987 5006 </li> 4988 5007 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 4989 <li>Location header field <a href="#rfc.xref.header.location.1">3. 3.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>5008 <li>Location header field <a href="#rfc.xref.header.location.1">3.2.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li> 4990 5009 </ul> 4991 5010 </li> 4992 5011 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 4993 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3. 3.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>5012 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3.2.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.2.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 4994 5013 <li>Methods 4995 5014 <ul> 4996 <li>CONNECT <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>3. 3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>4997 <li>DELETE <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>3. 3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>4998 <li>GET <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>3. 3.2</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>4999 <li>HEAD <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>3. 3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>5000 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.m.1"><b>3. 3.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>5001 <li>POST <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.m.4"><b>3. 3.4</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">C</a></li>5002 <li>PUT <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>3. 3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">C</a></li>5003 <li>TRACE <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.m.7"><b>3. 3.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>5015 <li>CONNECT <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>3.2.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 5016 <li>DELETE <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>3.2.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li> 5017 <li>GET <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>3.2.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li> 5018 <li>HEAD <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>3.2.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li> 5019 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.m.1"><b>3.2.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.2</a></li> 5020 <li>POST <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.m.4"><b>3.2.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li> 5021 <li>PUT <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>3.2.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5022 <li>TRACE <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.m.7"><b>3.2.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5004 5023 </ul> 5005 5024 </li> … … 5008 5027 </li> 5009 5028 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 5010 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.o.1"><b>3. 3.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>5029 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.o.1"><b>3.2.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.2</a></li> 5011 5030 </ul> 5012 5031 </li> 5013 5032 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5014 <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.2.1</a>, <a href="#rfc.xref.Part1.8">3. 3.1</a>, <a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.10">3.3.7</a>, <a href="#rfc.xref.Part1.11">3.3.8</a>, <a href="#rfc.xref.Part1.12">4</a>, <a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.16">4.5</a>, <a href="#rfc.xref.Part1.17">4.5</a>, <a href="#rfc.xref.Part1.18">4.6</a>, <a href="#rfc.xref.Part1.19">4.6</a>, <a href="#rfc.xref.Part1.20">4.7</a>, <a href="#rfc.xref.Part1.21">5.3.1</a>, <a href="#rfc.xref.Part1.22">5.3.2</a>, <a href="#rfc.xref.Part1.23">5.4.4</a>, <a href="#rfc.xref.Part1.24">5.4.6</a>, <a href="#rfc.xref.Part1.25">5.6.15</a>, <a href="#rfc.xref.Part1.26">5.7.6</a>, <a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.29">6.4</a>, <a href="#rfc.xref.Part1.30">6.4.1</a>, <a href="#rfc.xref.Part1.31">6.4.1</a>, <a href="#rfc.xref.Part1.32">7.1</a>, <a href="#rfc.xref.Part1.33">7.2</a>, <a href="#rfc.xref.Part1.34">8</a>, <a href="#rfc.xref.Part1.35">8.1</a>, <a href="#rfc.xref.Part1.36">10.8</a>, <a href="#rfc.xref.Part1.37">10.11</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.39">10.17</a>, <a href="#rfc.xref.Part1.40">10.18</a>, <a href="#rfc.xref.Part1.41">11.4</a>, <a href="#rfc.xref.Part1.42">11.4</a>, <a href="#rfc.xref.Part1.43">11.4</a>, <a href="#rfc.xref.Part1.44">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.45">C</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>5033 <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.2.1</a>, <a href="#rfc.xref.Part1.8">3.2.7</a>, <a href="#rfc.xref.Part1.9">3.2.7</a>, <a href="#rfc.xref.Part1.10">3.2.8</a>, <a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.12">4.5</a>, <a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.16">4.5</a>, <a href="#rfc.xref.Part1.17">4.6</a>, <a href="#rfc.xref.Part1.18">4.6</a>, <a href="#rfc.xref.Part1.19">4.7</a>, <a href="#rfc.xref.Part1.20">5.3.1</a>, <a href="#rfc.xref.Part1.21">5.3.2</a>, <a href="#rfc.xref.Part1.22">5.4.4</a>, <a href="#rfc.xref.Part1.23">5.4.6</a>, <a href="#rfc.xref.Part1.24">5.6.15</a>, <a href="#rfc.xref.Part1.25">5.7.6</a>, <a href="#rfc.xref.Part1.26">6.4</a>, <a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.29">6.4.1</a>, <a href="#rfc.xref.Part1.30">6.4.1</a>, <a href="#rfc.xref.Part1.31">7.1</a>, <a href="#rfc.xref.Part1.32">7.2</a>, <a href="#rfc.xref.Part1.33">8</a>, <a href="#rfc.xref.Part1.34">8.1</a>, <a href="#rfc.xref.Part1.35">10.8</a>, <a href="#rfc.xref.Part1.36">10.11</a>, <a href="#rfc.xref.Part1.37">10.17</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.39">10.18</a>, <a href="#rfc.xref.Part1.40">11.1.1</a>, <a href="#rfc.xref.Part1.41">11.4</a>, <a href="#rfc.xref.Part1.42">11.4</a>, <a href="#rfc.xref.Part1.43">11.4</a>, <a href="#rfc.xref.Part1.44">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.45">C</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> 5015 5034 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5016 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.2 3">5.4.4</a></li>5035 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.22">5.4.4</a></li> 5017 5036 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 5018 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.2 6">5.7.6</a></li>5037 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.25">5.7.6</a></li> 5019 5038 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li> 5020 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.1 2">4</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.40">10.18</a></li>5039 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.37">10.17</a>, <a href="#rfc.xref.Part1.39">10.18</a></li> 5021 5040 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a></li> 5022 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.1 4">4.5</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.54">D</a></li>5023 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1. 7">3.2.1</a>, <a href="#rfc.xref.Part1.24">5.4.6</a>, <a href="#rfc.xref.Part1.33">7.2</a>, <a href="#rfc.xref.Part1.34">8</a></li>5024 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.3 2">7.1</a></li>5025 <li><em>Section 4</em> <a href="#rfc.xref.Part1. 30">6.4.1</a></li>5026 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.1 7">4.5</a></li>5027 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.2 7">6.4</a>, <a href="#rfc.xref.Part1.41">11.4</a></li>5028 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.3 1">6.4.1</a></li>5029 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.2 8">6.4</a>, <a href="#rfc.xref.Part1.42">11.4</a></li>5030 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.2 9">6.4</a>, <a href="#rfc.xref.Part1.43">11.4</a></li>5031 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 9">4.6</a></li>5032 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1. 8">3.3.1</a>, <a href="#rfc.xref.Part1.11">3.3.8</a></li>5033 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.1 8">4.6</a></li>5034 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1. 20">4.7</a>, <a href="#rfc.xref.Part1.35">8.1</a>, <a href="#rfc.xref.Part1.36">10.8</a></li>5035 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1. 9">3.3.7</a>, <a href="#rfc.xref.Part1.39">10.17</a>, <a href="#rfc.xref.Part1.45">C</a></li>5036 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.1 6">4.5</a></li>5037 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.2 1">5.3.1</a>, <a href="#rfc.xref.Part1.37">10.11</a></li>5038 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.2 2">5.3.2</a>, <a href="#rfc.xref.Part1.25">5.6.15</a></li>5039 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1. 10">3.3.7</a></li>5041 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.13">4.5</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.54">D</a></li> 5042 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.23">5.4.6</a>, <a href="#rfc.xref.Part1.32">7.2</a>, <a href="#rfc.xref.Part1.33">8</a>, <a href="#rfc.xref.Part1.40">11.1.1</a></li> 5043 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.31">7.1</a></li> 5044 <li><em>Section 4</em> <a href="#rfc.xref.Part1.29">6.4.1</a></li> 5045 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.16">4.5</a></li> 5046 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.26">6.4</a>, <a href="#rfc.xref.Part1.41">11.4</a></li> 5047 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.30">6.4.1</a></li> 5048 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.42">11.4</a></li> 5049 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.43">11.4</a></li> 5050 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.18">4.6</a></li> 5051 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.7">3.2.1</a>, <a href="#rfc.xref.Part1.10">3.2.8</a></li> 5052 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.17">4.6</a></li> 5053 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.19">4.7</a>, <a href="#rfc.xref.Part1.34">8.1</a>, <a href="#rfc.xref.Part1.35">10.8</a></li> 5054 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.8">3.2.7</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.45">C</a></li> 5055 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.15">4.5</a></li> 5056 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.20">5.3.1</a>, <a href="#rfc.xref.Part1.36">10.11</a></li> 5057 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.21">5.3.2</a>, <a href="#rfc.xref.Part1.24">5.6.15</a></li> 5058 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.9">3.2.7</a></li> 5040 5059 <li><em>Section 9</em> <a href="#rfc.xref.Part1.44">13</a></li> 5041 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.1 3">4.5</a></li>5060 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.12">4.5</a></li> 5042 5061 </ul> 5043 5062 </li> 5044 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3. 3.2</a>, <a href="#rfc.xref.Part4.2">4.6</a>, <a href="#rfc.xref.Part4.3">4.6</a>, <a href="#rfc.xref.Part4.4">4.6</a>, <a href="#rfc.xref.Part4.5">4.6</a>, <a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.7">5.1</a>, <a href="#rfc.xref.Part4.8">5.1</a>, <a href="#rfc.xref.Part4.9">5.1</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.11">5.5</a>, <a href="#rfc.xref.Part4.12">8.2</a>, <a href="#rfc.xref.Part4.13">8.2</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>5063 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2.2</a>, <a href="#rfc.xref.Part4.2">4.6</a>, <a href="#rfc.xref.Part4.3">4.6</a>, <a href="#rfc.xref.Part4.4">4.6</a>, <a href="#rfc.xref.Part4.5">4.6</a>, <a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.7">5.1</a>, <a href="#rfc.xref.Part4.8">5.1</a>, <a href="#rfc.xref.Part4.9">5.1</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.11">5.5</a>, <a href="#rfc.xref.Part4.12">8.2</a>, <a href="#rfc.xref.Part4.13">8.2</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul> 5045 5064 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.13">8.2</a></li> 5046 5065 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.12">8.2</a></li> … … 5054 5073 </ul> 5055 5074 </li> 5056 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3. 3.2</a>, <a href="#rfc.xref.Part5.2">3.3.2</a>, <a href="#rfc.xref.Part5.3">3.3.5</a>, <a href="#rfc.xref.Part5.4">4.6</a>, <a href="#rfc.xref.Part5.5">4.6</a>, <a href="#rfc.xref.Part5.6">4.7</a>, <a href="#rfc.xref.Part5.7">5.1</a>, <a href="#rfc.xref.Part5.8">5.1</a>, <a href="#rfc.xref.Part5.9">5.1</a>, <a href="#rfc.xref.Part5.10">7.1</a>, <a href="#Part5"><b>14.1</b></a><ul>5075 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.2.2</a>, <a href="#rfc.xref.Part5.2">3.2.2</a>, <a href="#rfc.xref.Part5.3">3.2.5</a>, <a href="#rfc.xref.Part5.4">4.6</a>, <a href="#rfc.xref.Part5.5">4.6</a>, <a href="#rfc.xref.Part5.6">4.7</a>, <a href="#rfc.xref.Part5.7">5.1</a>, <a href="#rfc.xref.Part5.8">5.1</a>, <a href="#rfc.xref.Part5.9">5.1</a>, <a href="#rfc.xref.Part5.10">7.1</a>, <a href="#Part5"><b>14.1</b></a><ul> 5057 5076 <li><em>Section 3</em> <a href="#rfc.xref.Part5.7">5.1</a></li> 5058 5077 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.8">5.1</a></li> 5059 5078 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.9">5.1</a></li> 5060 5079 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.6">4.7</a></li> 5061 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.3">3. 3.5</a>, <a href="#rfc.xref.Part5.10">7.1</a></li>5080 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.3">3.2.5</a>, <a href="#rfc.xref.Part5.10">7.1</a></li> 5062 5081 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.4">4.6</a></li> 5063 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">3. 3.2</a>, <a href="#rfc.xref.Part5.5">4.6</a></li>5082 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">3.2.2</a>, <a href="#rfc.xref.Part5.5">4.6</a></li> 5064 5083 </ul> 5065 5084 </li> 5066 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3. 2.1</a>, <a href="#rfc.xref.Part6.2">3.3.2</a>, <a href="#rfc.xref.Part6.3">3.3.3</a>, <a href="#rfc.xref.Part6.4">3.3.4</a>, <a href="#rfc.xref.Part6.5">3.3.5</a>, <a href="#rfc.xref.Part6.6">3.3.6</a>, <a href="#rfc.xref.Part6.7">4.5</a>, <a href="#rfc.xref.Part6.8">4.7</a>, <a href="#rfc.xref.Part6.9">4.7</a>, <a href="#rfc.xref.Part6.10">5.2.1</a>, <a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.12">5.4.4</a>, <a href="#rfc.xref.Part6.13">5.4.4</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a>, <a href="#rfc.xref.Part6.18">8.2</a>, <a href="#rfc.xref.Part6.19">9.1</a>, <a href="#Part6"><b>14.1</b></a><ul>5067 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.4">3. 3.4</a></li>5085 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3.1.3</a>, <a href="#rfc.xref.Part6.2">3.2.2</a>, <a href="#rfc.xref.Part6.3">3.2.3</a>, <a href="#rfc.xref.Part6.4">3.2.4</a>, <a href="#rfc.xref.Part6.5">3.2.5</a>, <a href="#rfc.xref.Part6.6">3.2.6</a>, <a href="#rfc.xref.Part6.7">4.5</a>, <a href="#rfc.xref.Part6.8">4.7</a>, <a href="#rfc.xref.Part6.9">4.7</a>, <a href="#rfc.xref.Part6.10">5.2.1</a>, <a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.12">5.4.4</a>, <a href="#rfc.xref.Part6.13">5.4.4</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a>, <a href="#rfc.xref.Part6.18">8.2</a>, <a href="#rfc.xref.Part6.19">9.1</a>, <a href="#Part6"><b>14.1</b></a><ul> 5086 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.4">3.2.4</a></li> 5068 5087 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a></li> 5069 <li><em>Section 5</em> <a href="#rfc.xref.Part6.3">3. 3.3</a></li>5070 <li><em>Section 6</em> <a href="#rfc.xref.Part6.5">3. 3.5</a>, <a href="#rfc.xref.Part6.6">3.3.6</a></li>5088 <li><em>Section 5</em> <a href="#rfc.xref.Part6.3">3.2.3</a></li> 5089 <li><em>Section 6</em> <a href="#rfc.xref.Part6.5">3.2.5</a>, <a href="#rfc.xref.Part6.6">3.2.6</a></li> 5071 5090 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.8">4.7</a></li> 5072 5091 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.12">5.4.4</a></li> … … 5087 5106 </li> 5088 5107 <li>payload <a href="#rfc.iref.p.3">7</a></li> 5089 <li>POST method <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.p.1"><b>3. 3.4</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">C</a></li>5090 <li>PUT method <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>3. 3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">C</a></li>5108 <li>POST method <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.p.1"><b>3.2.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li> 5109 <li>PUT method <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>3.2.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5091 5110 </ul> 5092 5111 </li> … … 5158 5177 </ul> 5159 5178 </li> 5160 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1"> 3.2</a>, <a href="#rfc.xref.RFC5226.2">5.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a>, <a href="#RFC5226"><b>14.2</b></a><ul>5161 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1"> 3.2</a>, <a href="#rfc.xref.RFC5226.2">5.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a></li>5179 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5.2</a>, <a href="#rfc.xref.RFC5226.2">6.4.1</a>, <a href="#rfc.xref.RFC5226.3">11.1</a>, <a href="#RFC5226"><b>14.2</b></a><ul> 5180 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5.2</a>, <a href="#rfc.xref.RFC5226.2">6.4.1</a>, <a href="#rfc.xref.RFC5226.3">11.1</a></li> 5162 5181 </ul> 5163 5182 </li> … … 5176 5195 </ul> 5177 5196 </li> 5178 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">3. 3.5</a>, <a href="#RFC5789"><b>14.2</b></a></li>5197 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">3.2.5</a>, <a href="#RFC5789"><b>14.2</b></a></li> 5179 5198 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">4.5</a>, <a href="#RFC5987"><b>14.2</b></a></li> 5180 5199 <li><em>RFC6151</em> <a href="#RFC6151"><b>14.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li> … … 5183 5202 </li> 5184 5203 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 5185 <li> Safe Methods <a href="#rfc.iref.s.1"><b>3.1.1</b></a></li>5204 <li>safe <a href="#rfc.iref.s.1"><b>3.1.1</b></a></li> 5186 5205 <li>selected representation <a href="#rfc.iref.s.43"><b>8.2</b></a></li> 5187 5206 <li>Server header field <a href="#rfc.xref.header.server.1">4.7</a>, <a href="#rfc.iref.s.44"><b>10.17</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">C</a></li> … … 5238 5257 </li> 5239 5258 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 5240 <li>TRACE method <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.t.1"><b>3. 3.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>5259 <li>TRACE method <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.t.1"><b>3.2.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5241 5260 </ul> 5242 5261 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1839 r1840 327 327 <ttcol>Sec.</ttcol> 328 328 <c>GET</c> 329 <c> Retrievea current representation of the target resource.</c>329 <c>Transfer a current representation of the target resource.</c> 330 330 <c><xref target="GET" format="counter"/></c> 331 331 <c>HEAD</c> … … 354 354 <t> 355 355 The methods GET and HEAD &MUST; be supported by all general-purpose 356 servers. All other methods are &OPTIONAL;. If one of the above methods is 357 implemented by a server, the server &MUST; implement that method according 358 to the semantics defined for it in <xref target="method.definitions"/>. 359 </t> 360 <t> 361 Additional methods &MAY; be used in HTTP. New methods &SHOULD; be 362 registered within the IANA registry, as defined in 356 servers. All other methods are &OPTIONAL;. 357 When implemented, a server &MUST; implement the above methods according 358 to the semantics defined for them in <xref target="method.definitions"/>. 359 </t> 360 <t> 361 Additional methods &MAY; be used in HTTP; many have already been 362 standardized outside the scope of this specification and registered 363 within the HTTP Method Registry maintained by IANA, as defined in 363 364 <xref target="method.registry"/>. 364 365 </t> … … 377 378 378 379 <section title="Safe Methods" anchor="safe.methods"> 379 <iref item=" Safe Methods" primary="true"/>380 <iref item="safe" primary="true"/> 380 381 <t> 381 382 Request methods are considered "<x:dfn anchor="safe">safe</x:dfn>" if 382 their defined semantics are essentially read-only; i.e., the userdoes383 their defined semantics are essentially read-only; i.e., the client does 383 384 not request, and does not expect, any state change on the origin server 384 385 as a result of applying a safe method to a target resource. Likewise, … … 389 390 This definition of safe methods does not prevent an implementation from 390 391 including behavior that is potentially harmful, not entirely read-only, 391 or which causes side-effects while invoking a safe method. In fact, 392 some dynamic resources might consider that a feature. What is 393 important, however, is that the user did not request that additional 392 or which causes side-effects while invoking a safe method. What is 393 important, however, is that the client did not request that additional 394 394 behavior and cannot be held accountable for it. For example, 395 395 most servers append request information to access log files at the 396 396 completion of every response, regardless of the method, and that is 397 397 considered safe even though the log storage might become full and crash 398 the server. 398 the server. Likewise, a safe request initiated by selecting an 399 advertisement on the Web will often have the side-effect of charging an 400 advertising account. 399 401 </t> 400 402 <t> 401 403 The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe. 404 </t> 405 <t> 406 The purpose of distinguishing between safe and unsafe methods is to 407 allow automated retrieval processes (spiders) and cache performance 408 optimization (pre-fetching) to work without fear of causing harm. 409 In addition, it allows a user agent to apply appropriate constraints 410 on the automated use of unsafe methods when processing potentially 411 untrusted content. 402 412 </t> 403 413 <t> … … 405 415 presenting potential actions to a user, such that the user can be made 406 416 aware of an unsafe action before it is requested. 407 A user agent &SHOULD-NOT; make requests using unsafe methods as an408 automated result of the user selecting a safe action, unless the409 instruction for making the unsafe request came from the same origin server410 as the request target.411 417 </t> 412 418 <t> … … 415 421 owner's responsibility to ensure that the action is consistent with the 416 422 request method semantics. 417 For example, it is common for HTML form-based content editing software423 For example, it is common for Web-based content editing software 418 424 to use actions within query parameters, such as "page?do=delete". 419 425 If the purpose of such a resource is to perform an unsafe action, then … … 421 427 using a safe request method. Failure to do so will result in 422 428 unfortunate side-effects when automated processes perform a GET on 423 every URI reference , which often occurs for the sake of link maintenance,424 pre-fetching, or building a search index.429 every URI reference for the sake of link maintenance, pre-fetching, 430 building a search index, etc. 425 431 </t> 426 432 </section> 427 433 428 434 <section title="Idempotent Methods" anchor="idempotent.methods"> 429 <iref item=" Idempotent Methods" primary="true"/>430 <t> 431 Request methods can also have the property of "idempotence" in that,432 aside from error or expiration issues, the intended effect of multiple433 identical requests is the same as for a single request.435 <iref item="idempotent" primary="true"/> 436 <t> 437 Request methods are considered 438 "<x:dfn anchor="idempotent">idempotent</x:dfn>" if the intended effect 439 of multiple identical requests is the same as for a single request. 434 440 PUT, DELETE, and all safe request methods are idempotent. 435 It is important to note that idempotence refers only to changes 436 requested by the client: a server is free to change its state due 437 to multiple requests for the purpose of tracking those requests, 438 versioning of results, etc. 439 </t> 440 </section> 441 </section> 442 443 <section title="Method Registry" anchor="method.registry"> 444 <t> 445 The HTTP Method Registry defines the name space for the method token in the 446 Request line of an HTTP request. 447 </t> 448 <t> 449 Registrations &MUST; include the following fields: 450 <list style="symbols"> 451 <t>Method Name (see <xref target="methods"/>)</t> 452 <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t> 453 <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t> 454 <t>Pointer to specification text</t> 455 </list> 456 </t> 457 <t> 458 Values to be added to this name space require IETF Review 459 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). 460 </t> 461 <t> 462 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>. 463 </t> 464 465 <section title="Considerations for New Methods" anchor="considerations.for.new.methods"> 466 <t> 467 When it is necessary to express new semantics for a HTTP request that 468 aren't specific to a single application or media type, and currently defined 469 methods are inadequate, it might be appropriate to register a new method. 470 </t> 471 <t> 472 HTTP methods are generic; that is, they are potentially applicable to any 473 resource, not just one particular media type, "type" of resource, or 474 application. As such, it is preferred that new HTTP methods be registered 475 in a document that isn't specific to a single application, so that this is 476 clear. 477 </t> 478 <t> 479 Due to the parsing rules defined in &message-body;, definitions of HTTP 480 methods cannot prohibit the presence of a message body on either the request 481 or the response message (with responses to HEAD requests being the single 482 exception). Definitions of new methods cannot change this rule, but they can 483 specify that only zero-length bodies (as opposed to absent bodies) are allowed. 484 </t> 485 <t> 486 New method definitions need to indicate whether they are safe (<xref 487 target="safe.methods"/>), what semantics (if any) the request body has, 488 and whether they are idempotent (<xref target="idempotent.methods"/>). 489 They also need to state whether they can be cached (&caching;); in 490 particular under what conditions a cache can store the response, and under 491 what conditions such a stored response can be used to satisfy a subsequent 492 request. 441 </t> 442 <t> 443 Like the definition of safe, the idempotent property only applies to 444 what has been requested by the user; a server is free to log each request 445 separately, retain a revision control history, or implement other 446 non-idempotent side-effects for each idempotent request. 447 </t> 448 <t> 449 Idempotent methods are distinguished because the request can be repeated 450 automatically if a communication failure occurs before the client is 451 able to read the server's response. For example, if a client sends a PUT 452 request and the underlying connection is closed before any response is 453 received, then it can establish a new connection and retry the request 454 because it knows that repeating the request will have the same effect 455 even if the original request succeeded. Note, however, that repeated 456 failures would indicate a problem within the server. 457 </t> 458 </section> 459 460 <section title="Cacheable Methods" anchor="cacheable.methods"> 461 <iref item="cacheable" primary="true"/> 462 <t> 463 Request methods are considered 464 "<x:dfn anchor="cacheable">cacheable</x:dfn>" if it is possible and useful 465 to answer a current client request with a stored response from a prior 466 request. GET and HEAD are defined to be cacheable. In general, safe 467 methods that do not depend on a current or authoritative response are 468 also cacheable, though the overwhelming majority of caches only support 469 GET and HEAD. HTTP requirements for cache behavior and cacheable responses 470 are defined in &caching;. 493 471 </t> 494 472 </section> … … 4043 4021 <section title="IANA Considerations" anchor="IANA.considerations"> 4044 4022 4045 <section title="Method Registry" anchor="method.registration"> 4046 <t> 4047 The registration procedure for HTTP request methods is defined by 4048 <xref target="method.registry"/> of this document. 4049 </t> 4023 <section title="Method Registry" anchor="method.registry"> 4024 <t> 4025 The HTTP Method Registry defines the name space for the method token in the 4026 Request line of an HTTP request. 4027 </t> 4028 <t> 4029 Registrations &MUST; include the following fields: 4030 <list style="symbols"> 4031 <t>Method Name (see <xref target="methods"/>)</t> 4032 <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t> 4033 <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t> 4034 <t>Pointer to specification text</t> 4035 </list> 4036 </t> 4037 <t> 4038 Values to be added to this name space require IETF Review 4039 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). 4040 </t> 4041 <t> 4042 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>. 4043 </t> 4044 4045 <section title="Considerations for New Methods" anchor="considerations.for.new.methods"> 4046 <t> 4047 Standardized HTTP methods are generic; that is, they are potentially 4048 applicable to any resource, not just one particular media type, kind of 4049 resource, or application. As such, it is preferred that new HTTP methods 4050 be registered in a document that isn't specific to a single application or 4051 data format, since orthogonal technologies deserve orthogonal specification. 4052 </t> 4053 <t> 4054 Since HTTP message parsing (&message-body;) is independent of method 4055 semantics (aside from responses to HEAD), definitions of new HTTP methods 4056 cannot change the parsing algorithm or prohibit the presence of a message 4057 body on either the request or the response message. 4058 Definitions of new methods can specify that only zero-length bodies are 4059 allowed, which would imply that each such messages would be required to 4060 contain a Content-Length header field with a value of "0". 4061 </t> 4062 <t> 4063 New method definitions need to indicate whether they are safe (<xref 4064 target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>), 4065 or cacheable (<xref target="cacheable.methods"/>), and what 4066 semantics are to be associated with the request body if any is present 4067 in the request. If a method is cacheable, the method definition ought 4068 to describe how, and under what conditions, a cache can store a response 4069 and use it to satisfy a subsequent request. 4070 </t> 4071 </section> 4072 4073 <section title="Registrations" anchor="method.registration"> 4050 4074 <t> 4051 4075 The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/> … … 4110 4134 <!--(END)--> 4111 4135 <?ENDINC p2-semantics.iana-methods ?> 4136 </section> 4112 4137 </section> 4113 4138
Note: See TracChangeset
for help on using the changeset viewer.