Changeset 1842 for draft-ietf-httpbis
- Timestamp:
- 01/09/12 05:32:48 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1841 r1842 587 587 <li><a href="#rfc.section.2">2.</a> <a href="#resource">Resource</a></li> 588 588 <li><a href="#rfc.section.3">3.</a> <a href="#methods">Request Methods</a><ul> 589 <li><a href="#rfc.section.3.1">3.1</a> <a href="#method.properties">Common Method Properties</a><ul> 590 <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#safe.methods">Safe Methods</a></li> 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> 589 <li><a href="#rfc.section.3.1">3.1</a> <a href="#method.overview">Overview</a></li> 590 <li><a href="#rfc.section.3.2">3.2</a> <a href="#method.properties">Common Method Properties</a><ul> 591 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#safe.methods">Safe Methods</a></li> 592 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#idempotent.methods">Idempotent Methods</a></li> 593 <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#cacheable.methods">Cacheable Methods</a></li> 593 594 </ul> 594 595 </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>596 <li><a href="#rfc.section.3.3">3.3</a> <a href="#method.definitions">Method Definitions</a><ul> 597 <li><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#OPTIONS">OPTIONS</a></li> 598 <li><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#GET">GET</a></li> 599 <li><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#HEAD">HEAD</a></li> 600 <li><a href="#rfc.section.3.3.4">3.3.4</a> <a href="#POST">POST</a></li> 601 <li><a href="#rfc.section.3.3.5">3.3.5</a> <a href="#PUT">PUT</a></li> 602 <li><a href="#rfc.section.3.3.6">3.3.6</a> <a href="#DELETE">DELETE</a></li> 603 <li><a href="#rfc.section.3.3.7">3.3.7</a> <a href="#TRACE">TRACE</a></li> 604 <li><a href="#rfc.section.3.3.8">3.3.8</a> <a href="#CONNECT">CONNECT</a></li> 604 605 </ul> 605 606 </li> … … 847 848 </p> 848 849 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="methods" href="#methods">Request Methods</a></h1> 849 <p id="rfc.section.3.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made 850 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="method.overview" href="#method.overview">Overview</a></h2> 851 <p id="rfc.section.3.1.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made 850 852 this request and what is expected by the client as a successful result. The request semantics <em class="bcp14">MAY</em> be further specialized by the semantics of some header fields when present in a request (<a href="#request.fields" title="Request-modifier Header Fields">Section 4.1</a>) if those additional semantics do not conflict with the method. 851 853 </p> 852 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method s" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a>853 </pre><p id="rfc.section.3. p.3">HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned854 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a> 855 </pre><p id="rfc.section.3.1.p.3">HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned 854 856 as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would 855 857 apply semantics. The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive 856 858 method names. 857 859 </p> 858 <p id="rfc.section.3. p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide860 <p id="rfc.section.3.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide 859 861 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are 860 862 implemented or allowed. 861 863 </p> 862 <p id="rfc.section.3. p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table.864 <p id="rfc.section.3.1.p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. 863 865 By convention, standardized methods are defined in all-uppercase ASCII letters. 864 866 </p> 865 867 <div id="rfc.table.1"> 866 <div id=" method.overview"></div>868 <div id="table.of.methods"></div> 867 869 <table class="tt full left" cellpadding="3" cellspacing="0"> 868 870 <thead> … … 877 879 <td class="left">GET</td> 878 880 <td class="left">Transfer a current representation of the target resource.</td> 879 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3. 2.2</a></td>881 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.3.2</a></td> 880 882 </tr> 881 883 <tr> 882 884 <td class="left">HEAD</td> 883 885 <td class="left">Same as GET, but do not include a message body in the response.</td> 884 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3. 2.3</a></td>886 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.3.3</a></td> 885 887 </tr> 886 888 <tr> 887 889 <td class="left">POST</td> 888 890 <td class="left">Perform resource-specific processing on the request payload.</td> 889 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3. 2.4</a></td>891 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.3.4</a></td> 890 892 </tr> 891 893 <tr> 892 894 <td class="left">PUT</td> 893 895 <td class="left">Replace all current representations of the target resource with the request payload.</td> 894 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3. 2.5</a></td>896 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.3.5</a></td> 895 897 </tr> 896 898 <tr> 897 899 <td class="left">DELETE</td> 898 900 <td class="left">Remove all current representations of the target resource.</td> 899 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3. 2.6</a></td>901 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.3.6</a></td> 900 902 </tr> 901 903 <tr> 902 904 <td class="left">CONNECT</td> 903 905 <td class="left">Establish a tunnel to the server identified by the target resource.</td> 904 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3. 2.8</a></td>906 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.3.8</a></td> 905 907 </tr> 906 908 <tr> 907 909 <td class="left">OPTIONS</td> 908 910 <td class="left">Describe the communication options for the target resource.</td> 909 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3. 2.1</a></td>911 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.3.1</a></td> 910 912 </tr> 911 913 <tr> 912 914 <td class="left">TRACE</td> 913 915 <td class="left">Perform a message loop-back test along the path to the target resource.</td> 914 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3. 2.7</a></td>916 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.3.7</a></td> 915 917 </tr> 916 918 </tbody> 917 919 </table> 918 920 </div> 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 HTTP921 <p id="rfc.section.3.1.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.3</a>. 922 </p> 923 <p id="rfc.section.3.1.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 924 Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 11.1</a>. 923 925 </p> 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 or926 <p id="rfc.section.3.1.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 925 927 not implemented by an origin server, the origin server <em class="bcp14">SHOULD</em> respond with the <a href="#status.501" class="smpl">501 (Not Implemented)</a> status code. When a request message is received that is known by an origin server but not allowed for the target resource, 926 928 the origin server <em class="bcp14">SHOULD</em> respond with the <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> status code. 927 929 </p> 928 <h2 id="rfc.section.3. 1"><a href="#rfc.section.3.1">3.1</a> <a id="method.properties" href="#method.properties">Common Method Properties</a></h2>930 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="method.properties" href="#method.properties">Common Method Properties</a></h2> 929 931 <div id="rfc.iref.s.1"></div> 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>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 state932 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 933 <p id="rfc.section.3.2.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 934 change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe 933 935 method is not expected to cause any harm, loss of property, or unusual burden on the origin server. 934 936 </p> 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, not937 <p id="rfc.section.3.2.1.p.2">This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, not 936 938 entirely read-only, or which causes side-effects while invoking a safe method. What is important, however, is that the client 937 939 did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information … … 940 942 the Web will often have the side-effect of charging an advertising account. 941 943 </p> 942 <p id="rfc.section.3. 1.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p>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 cache944 <p id="rfc.section.3.2.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p> 945 <p id="rfc.section.3.2.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache 944 946 performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply 945 947 appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content. 946 948 </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 aware949 <p id="rfc.section.3.2.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 950 of an unsafe action before it is requested. 949 951 </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,952 <p id="rfc.section.3.2.1.p.6">When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, 951 953 it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, 952 954 it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the … … 956 958 </p> 957 959 <div id="rfc.iref.i.1"></div> 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>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 request960 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 961 <p id="rfc.section.3.2.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 962 methods are idempotent. 961 963 </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 free964 <p id="rfc.section.3.2.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 965 to log each request separately, retain a revision control history, or implement other non-idempotent side-effects for each 964 966 idempotent request. 965 967 </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 before968 <p id="rfc.section.3.2.2.p.3">Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before 967 969 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 that969 repeating the request will have the same effect even if the original request succeeded. Note, however, that repeated failures970 would indicate a problem within the server.970 is closed before any response is received, then it can establish a new connection and retry the idempotent request because 971 it knows that repeating the request will have the same effect even if the original request succeeded. Note, however, that 972 repeated failures would indicate a problem within the server. 971 973 </p> 972 974 <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 HEAD975 are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are alsocacheable,975 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="cacheable.methods" href="#cacheable.methods">Cacheable Methods</a></h3> 976 <p id="rfc.section.3.2.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 977 are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable, 976 978 though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses 977 979 are defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 978 980 </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>981 <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> 982 <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> 981 983 <div id="rfc.iref.o.1"></div> 982 984 <div id="rfc.iref.m.1"></div> 983 <p id="rfc.section.3. 2.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified985 <p id="rfc.section.3.3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 984 986 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 985 987 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 986 988 </p> 987 <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 OPTIONS989 <p id="rfc.section.3.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p> 990 <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 OPTIONS 989 991 body to make more detailed queries on the server. 990 992 </p> 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.993 <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.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. 992 994 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 993 995 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 994 996 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 995 997 </p> 996 <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 communicating998 <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 communicating 997 999 with that resource. 998 1000 </p> 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,1001 <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, 1000 1002 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". 1001 1003 </p> 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>1004 <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. 1005 </p> 1006 <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> 1005 1007 <div id="rfc.iref.g.2"></div> 1006 1008 <div id="rfc.iref.m.2"></div> 1007 <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 representation1009 <p id="rfc.section.3.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1010 <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 representation 1009 1011 in the response and not the source text of the process, unless that text happens to be the output of the process. 1010 1012 </p> 1011 <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 conditional1013 <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 conditional 1012 1014 header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations 1013 1015 to be refreshed without requiring multiple requests or transferring data already held by the client. 1014 1016 </p> 1015 <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 representations1017 <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 representations 1016 1018 to be completed without transferring data already held by the client. 1017 1019 </p> 1018 <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 implementations1020 <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 implementations 1019 1021 to reject the request. 1020 1022 </p> 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>1023 <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>). 1024 </p> 1025 <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. 1026 </p> 1027 <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> 1026 1028 <div id="rfc.iref.h.1"></div> 1027 1029 <div id="rfc.iref.m.3"></div> 1028 <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 the1030 <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 the 1029 1031 representation implied by the request without transferring the representation body. This method is often used for testing 1030 1032 hypertext links for validity, accessibility, and recent modification. 1031 1033 </p> 1032 <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 implementations1034 <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>. 1035 </p> 1036 <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 implementations 1035 1037 to reject the request. 1036 1038 </p> 1037 1039 <div id="rfc.iref.p.1"></div> 1038 1040 <div id="rfc.iref.m.4"></div> 1039 <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 processed1041 <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> 1042 <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 processed 1041 1043 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1042 1044 </p> … … 1047 1049 <li>Extending a database through an append operation.</li> 1048 1050 </ul> 1049 <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 request1051 <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 request 1050 1052 URI. 1051 1053 </p> 1052 <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 describes1054 <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 describes 1053 1055 the result. 1054 1056 </p> 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>1057 <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>). 1058 </p> 1059 <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. 1060 </p> 1061 <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. 1062 </p> 1063 <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> 1062 1064 <div id="rfc.iref.p.2"></div> 1063 1065 <div id="rfc.iref.m.5"></div> 1064 <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 representation1066 <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 representation 1065 1067 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1066 1068 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 … … 1069 1071 by the origin server. 1070 1072 </p> 1071 <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 accordance1073 <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 accordance 1072 1074 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. 1073 1075 </p> 1074 <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 cannot1076 <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). 1077 </p> 1078 <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 cannot 1077 1079 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1078 1080 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent … … 1080 1082 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. 1081 1083 </p> 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:1084 <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: 1083 1085 </p> 1084 1086 <ol class="la"> … … 1091 1093 </li> 1092 1094 </ol> 1093 <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 intent1095 <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 intent 1094 1096 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 1095 1097 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how … … 1098 1100 the server. 1099 1101 </p> 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.1102 <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. 1101 1103 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 1102 1104 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT … … 1104 1106 and visible to intermediaries, even though the exact effect is only known by the origin server. 1105 1107 </p> 1106 <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 that1108 <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 that 1107 1109 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 1108 1110 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 1109 1111 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. 1110 1112 </p> 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)1113 <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) 1112 1114 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 1113 1115 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new … … 1115 1117 the related resources. 1116 1118 </p> 1117 <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 full1119 <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 full 1118 1120 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1119 1121 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for 1120 1122 example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). 1121 1123 </p> 1122 <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 responses1124 <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 responses 1123 1125 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>). 1124 1126 </p> 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>1127 <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> 1126 1128 <div id="rfc.iref.d.1"></div> 1127 1129 <div id="rfc.iref.m.6"></div> 1128 <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 operation1130 <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 operation 1129 1131 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1130 1132 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 1131 1133 location. 1132 1134 </p> 1133 <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 existing1135 <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. 1136 </p> 1137 <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 existing 1136 1138 implementations to reject the request. 1137 1139 </p> 1138 <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 responses1140 <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 responses 1139 1141 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>). 1140 1142 </p> 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>1143 <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> 1142 1144 <div id="rfc.iref.t.1"></div> 1143 1145 <div id="rfc.iref.m.7"></div> 1144 <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 testing1146 <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. 1147 </p> 1148 <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 testing 1147 1149 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 1148 1150 messages in an infinite loop. 1149 1151 </p> 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.1152 <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.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 1153 </p> 1152 1154 <div id="rfc.iref.c.3"></div> 1153 1155 <div id="rfc.iref.m.8"></div> 1154 <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 restrict1156 <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> 1157 <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 restrict 1156 1158 its behavior to blind forwarding of packets until the connection is closed. 1157 1159 </p> 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.1160 <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.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. 1159 1161 For example, 1160 1162 </p> … … 1162 1164 Host: server.example.com:80 1163 1165 1164 </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 has1166 </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 has 1165 1167 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1166 1168 after the blank line that concludes the successful response's header block. 1167 1169 </p> 1168 <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 remains1170 <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. 1171 </p> 1172 <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 remains 1171 1173 governed by HTTP. 1172 1174 </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>1175 <p id="rfc.section.3.3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1174 1176 <div id="rfc.figure.u.3"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1175 1177 Host: server.example.com:80 1176 1178 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1177 1179 1178 </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 implementations1180 </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 implementations 1179 1181 to reject the request. 1180 1182 </p> 1181 <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 discarded1183 <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 discarded 1182 1184 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1183 1185 </p> 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,1186 <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, 1185 1187 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. 1186 1188 </p> 1187 <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 to1189 <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 to 1188 1190 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1189 1191 peer undelivered, that data will be discarded. 1190 1192 </p> 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.1193 <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. 1192 1194 </p> 1193 1195 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> … … 1807 1809 <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. 1808 1810 If the required action involves a subsequent HTTP request, it <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is 1809 known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 3. 1.1</a>.1811 known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 3.2.1</a>. 1810 1812 </p> 1811 1813 <p id="rfc.section.5.5.p.2">There are several types of redirects: </p> … … 1840 1842 <p id="rfc.section.5.5.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.13</a>. 1841 1843 </p> 1842 <p id="rfc.section.5.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 3. 1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was1844 <p id="rfc.section.5.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 3.2.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was 1843 1845 issued. 1844 1846 </p> … … 1929 1931 <p> <b>Note:</b> This status code is similar to <a href="#status.302" class="smpl">302 (Found)</a>, except that it does not allow rewriting the request method from POST to GET. This specification defines no equivalent counterpart 1930 1932 for <a href="#status.301" class="smpl">301 (Moved 1931 Permanently)</a> (<a href="# draft-reschke-http-status-308" id="rfc.xref.draft-reschke-http-status-308.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[draft-reschke-http-status-308]</cite></a>, however, defines the status code 308 (Permanent Redirect) for this purpose).1933 Permanently)</a> (<a href="#status-308" id="rfc.xref.status-308.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[status-308]</cite></a>, however, defines the status code 308 (Permanent Redirect) for this purpose). 1932 1934 </p> 1933 1935 </div> … … 2817 2819 is strictly to inform the recipient of valid request methods associated with the resource. 2818 2820 </p> 2819 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method s" class="smpl">method</a>2821 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method.overview" class="smpl">method</a> 2820 2822 </pre><p id="rfc.section.10.5.p.3">Example of use:</p> 2821 2823 <div id="rfc.figure.u.35"></div><pre class="text"> Allow: GET, HEAD, PUT … … 3042 3044 <div id="rfc.iref.h.15"></div> 3043 3045 <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> 3044 <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 attempting3046 <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 attempting 3045 3047 to trace a request which appears to be failing or looping mid-chain. 3046 3048 </p> … … 3134 3136 <li>Method Name (see <a href="#methods" title="Request Methods">Section 3</a>) 3135 3137 </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>)3138 <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.2.1</a>) 3139 </li> 3140 <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 3.2.1</a>) 3139 3141 </li> 3140 3142 <li>Pointer to specification text</li> … … 3154 3156 a Content-Length header field with a value of "0". 3155 3157 </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,3158 <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.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 3.2.2</a>), or cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section 3.2.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 3159 the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy 3158 3160 a subsequent request. … … 3177 3179 <td class="left">no</td> 3178 3180 <td class="left">no</td> 3179 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 3. 2.8</a>3181 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 3.3.8</a> 3180 3182 </td> 3181 3183 </tr> … … 3184 3186 <td class="left">no</td> 3185 3187 <td class="left">yes</td> 3186 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 3. 2.6</a>3188 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 3.3.6</a> 3187 3189 </td> 3188 3190 </tr> … … 3191 3193 <td class="left">yes</td> 3192 3194 <td class="left">yes</td> 3193 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 3. 2.2</a>3195 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 3.3.2</a> 3194 3196 </td> 3195 3197 </tr> … … 3198 3200 <td class="left">yes</td> 3199 3201 <td class="left">yes</td> 3200 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 3. 2.3</a>3202 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 3.3.3</a> 3201 3203 </td> 3202 3204 </tr> … … 3205 3207 <td class="left">yes</td> 3206 3208 <td class="left">yes</td> 3207 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 3. 2.1</a>3209 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 3.3.1</a> 3208 3210 </td> 3209 3211 </tr> … … 3212 3214 <td class="left">no</td> 3213 3215 <td class="left">no</td> 3214 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 3. 2.4</a>3216 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 3.3.4</a> 3215 3217 </td> 3216 3218 </tr> … … 3219 3221 <td class="left">no</td> 3220 3222 <td class="left">yes</td> 3221 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 3. 2.5</a>3223 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 3.3.5</a> 3222 3224 </td> 3223 3225 </tr> … … 3226 3228 <td class="left">yes</td> 3227 3229 <td class="left">yes</td> 3228 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 3. 2.7</a>3230 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 3.3.7</a> 3229 3231 </td> 3230 3232 </tr> … … 3697 3699 user. 3698 3700 </p> 3699 <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 used3701 <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 used 3700 3702 to collect data from the client. 3701 3703 </p> … … 3831 3833 <tr> 3832 3834 <td class="reference"><b id="REST">[REST]</b></td> 3833 <td class="top">Fielding, R., “<a href="http:// www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures</a>”, Sep 2000, <<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</a>>.3835 <td class="top">Fielding, R., “<a href="http://roy.gbiv.com/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures</a>”, Doctoral Dissertation, University of California, Irvine, September 2000, <<a href="http://roy.gbiv.com/pubs/dissertation/top.htm">http://roy.gbiv.com/pubs/dissertation/top.htm</a>>. 3834 3836 </td> 3835 3837 </tr> … … 3935 3937 </tr> 3936 3938 <tr> 3937 <td class="reference"><b id=" draft-reschke-http-status-308">[draft-reschke-http-status-308]</b></td>3939 <td class="reference"><b id="status-308">[status-308]</b></td> 3938 3940 <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http://tools.ietf.org/html/draft-reschke-http-status-308-07">The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)</a>”, Internet-Draft draft-reschke-http-status-308-07 (work in progress), March 2012. 3939 3941 </td> … … 4019 4021 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 11.1</a>) 4020 4022 </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>)4023 <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>) 4024 </p> 4025 <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>) 4026 </p> 4027 <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>) 4026 4028 </p> 4027 4029 <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>) … … 4189 4191 ";" OWS parameter ) 4190 4192 <a href="#media.types" class="smpl">media-type</a> = type "/" subtype *( OWS ";" OWS parameter ) 4191 <a href="#method s" class="smpl">method</a> = token4193 <a href="#method.overview" class="smpl">method</a> = token 4192 4194 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT 4193 4195 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan … … 4863 4865 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">4.6</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc.xref.header.accept-encoding.3">9.1</a>, <a href="#rfc.iref.a.3"><b>10.3</b></a>, <a href="#rfc.xref.header.accept-encoding.4">11.3</a>, <a href="#rfc.xref.header.accept-encoding.5">11.4</a></li> 4864 4866 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">4.6</a>, <a href="#rfc.xref.header.accept-language.2">9.1</a>, <a href="#rfc.iref.a.4"><b>10.4</b></a>, <a href="#rfc.xref.header.accept-language.3">11.3</a></li> 4865 <li>Allow header field <a href="#rfc.xref.header.allow.1">3 </a>, <a href="#rfc.xref.header.allow.2">4.7</a>, <a href="#rfc.iref.a.5"><b>10.5</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li>4867 <li>Allow header field <a href="#rfc.xref.header.allow.1">3.1</a>, <a href="#rfc.xref.header.allow.2">4.7</a>, <a href="#rfc.iref.a.5"><b>10.5</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li> 4866 4868 </ul> 4867 4869 </li> 4868 4870 <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>4871 <li>cacheable <a href="#rfc.iref.c.2"><b>3.2.3</b></a></li> 4870 4872 <li>Coding Format 4871 4873 <ul> … … 4876 4878 </li> 4877 4879 <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>4880 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">3.1</a>, <a href="#rfc.iref.c.3"><b>3.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 4879 4881 <li>content negotiation <a href="#rfc.iref.c.1">1</a></li> 4880 4882 <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 4883 <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>4884 <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.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 4885 <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 4886 <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> … … 4888 4890 <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> 4889 4891 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.4</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> 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> 4892 <li>DELETE method <a href="#rfc.xref.DELETE.1">3.1</a>, <a href="#rfc.iref.d.1"><b>3.3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li> 4892 4893 </ul> 4893 4894 </li> … … 4906 4907 </li> 4907 4908 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 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>4909 <li>GET method <a href="#rfc.xref.GET.1">3.1</a>, <a href="#rfc.iref.g.2"><b>3.3.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li> 4909 4910 <li><tt>Grammar</tt> 4910 4911 <ul> … … 4946 4947 <li><tt>media-range</tt> <a href="#rfc.iref.g.34"><b>10.1</b></a></li> 4947 4948 <li><tt>media-type</tt> <a href="#rfc.iref.g.24"><b>6.5</b></a></li> 4948 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>3 </b></a></li>4949 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>3.1</b></a></li> 4949 4950 <li><tt>MIME-Version</tt> <a href="#rfc.iref.g.61"><b>A.1</b></a></li> 4950 4951 <li><tt>minute</tt> <a href="#rfc.iref.g.8"><b>6.1</b></a></li> … … 4974 4975 </li> 4975 4976 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 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>4977 <li>HEAD method <a href="#rfc.xref.HEAD.1">3.1</a>, <a href="#rfc.iref.h.1"><b>3.3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li> 4977 4978 <li>Header Fields 4978 4979 <ul> … … 4981 4982 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">4.6</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc.xref.header.accept-encoding.3">9.1</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a>, <a href="#rfc.xref.header.accept-encoding.4">11.3</a>, <a href="#rfc.xref.header.accept-encoding.5">11.4</a></li> 4982 4983 <li>Accept-Language <a href="#rfc.xref.header.accept-language.1">4.6</a>, <a href="#rfc.xref.header.accept-language.2">9.1</a>, <a href="#rfc.iref.h.5"><b>10.4</b></a>, <a href="#rfc.xref.header.accept-language.3">11.3</a></li> 4983 <li>Allow <a href="#rfc.xref.header.allow.1">3 </a>, <a href="#rfc.xref.header.allow.2">4.7</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li>4984 <li>Allow <a href="#rfc.xref.header.allow.1">3.1</a>, <a href="#rfc.xref.header.allow.2">4.7</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li> 4984 4985 <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> 4985 4986 <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> 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>4987 <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> 4987 4988 <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> 4988 4989 <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> … … 4990 4991 <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> 4991 4992 <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> 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>4993 <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> 4994 <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> 4994 4995 <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> 4995 4996 <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> … … 5002 5003 </li> 5003 5004 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 5004 <li>idempotent <a href="#rfc.iref.i.1"><b>3. 1.2</b></a></li>5005 <li>idempotent <a href="#rfc.iref.i.1"><b>3.2.2</b></a></li> 5005 5006 </ul> 5006 5007 </li> 5007 5008 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 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>5009 <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> 5009 5010 </ul> 5010 5011 </li> 5011 5012 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 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>5013 <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> 5013 5014 <li>Methods 5014 5015 <ul> 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>5016 <li>CONNECT <a href="#rfc.xref.CONNECT.1">3.1</a>, <a href="#rfc.iref.m.8"><b>3.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 5017 <li>DELETE <a href="#rfc.xref.DELETE.1">3.1</a>, <a href="#rfc.iref.m.6"><b>3.3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li> 5018 <li>GET <a href="#rfc.xref.GET.1">3.1</a>, <a href="#rfc.iref.m.2"><b>3.3.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li> 5019 <li>HEAD <a href="#rfc.xref.HEAD.1">3.1</a>, <a href="#rfc.iref.m.3"><b>3.3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li> 5020 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">3.1</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.2</a></li> 5021 <li>POST <a href="#rfc.xref.POST.1">3.1</a>, <a href="#rfc.iref.m.4"><b>3.3.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li> 5022 <li>PUT <a href="#rfc.xref.PUT.1">3.1</a>, <a href="#rfc.iref.m.5"><b>3.3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5023 <li>TRACE <a href="#rfc.xref.TRACE.1">3.1</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.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5023 5024 </ul> 5024 5025 </li> … … 5027 5028 </li> 5028 5029 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 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>5030 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">3.1</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.2</a></li> 5030 5031 </ul> 5031 5032 </li> 5032 5033 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></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>5034 <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.3.1</a>, <a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.10">3.3.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> 5034 5035 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5035 5036 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.22">5.4.4</a></li> … … 5049 5050 <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 5051 <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.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.7">3.3.1</a>, <a href="#rfc.xref.Part1.10">3.3.8</a></li> 5052 5053 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.17">4.6</a></li> 5053 5054 <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 5.7</em> <a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.45">C</a></li> 5055 5056 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.15">4.5</a></li> 5056 5057 <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 5058 <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>5059 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.9">3.3.7</a></li> 5059 5060 <li><em>Section 9</em> <a href="#rfc.xref.Part1.44">13</a></li> 5060 5061 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.12">4.5</a></li> 5061 5062 </ul> 5062 5063 </li> 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>5064 <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> 5064 5065 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.13">8.2</a></li> 5065 5066 <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> … … 5073 5074 </ul> 5074 5075 </li> 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>5076 <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> 5076 5077 <li><em>Section 3</em> <a href="#rfc.xref.Part5.7">5.1</a></li> 5077 5078 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.8">5.1</a></li> 5078 5079 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.9">5.1</a></li> 5079 5080 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.6">4.7</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>5081 <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> 5081 5082 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.4">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>5083 <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> 5083 5084 </ul> 5084 5085 </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>5086 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3.2.3</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> 5087 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.4">3.3.4</a></li> 5087 5088 <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> 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>5089 <li><em>Section 5</em> <a href="#rfc.xref.Part6.3">3.3.3</a></li> 5090 <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> 5090 5091 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.8">4.7</a></li> 5091 5092 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.12">5.4.4</a></li> … … 5106 5107 </li> 5107 5108 <li>payload <a href="#rfc.iref.p.3">7</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>5109 <li>POST method <a href="#rfc.xref.POST.1">3.1</a>, <a href="#rfc.iref.p.1"><b>3.3.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li> 5110 <li>PUT method <a href="#rfc.xref.PUT.1">3.1</a>, <a href="#rfc.iref.p.2"><b>3.3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5110 5111 </ul> 5111 5112 </li> … … 5113 5114 <li>Referer header field <a href="#rfc.xref.header.referer.1">4.6</a>, <a href="#rfc.iref.r.2"><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> 5114 5115 <li>representation <a href="#rfc.iref.r.1">8</a></li> 5115 <li><em>REST</em> <a href="#rfc.xref.REST.1">3 </a>, <a href="#REST"><b>14.2</b></a></li>5116 <li><em>REST</em> <a href="#rfc.xref.REST.1">3.1</a>, <a href="#REST"><b>14.2</b></a></li> 5116 5117 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">4.7</a>, <a href="#rfc.xref.header.retry-after.2">5.7.4</a>, <a href="#rfc.iref.r.3"><b>10.16</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li> 5117 5118 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>14.2</b></a><ul> … … 5195 5196 </ul> 5196 5197 </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>5198 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">3.3.5</a>, <a href="#RFC5789"><b>14.2</b></a></li> 5198 5199 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">4.5</a>, <a href="#RFC5987"><b>14.2</b></a></li> 5199 5200 <li><em>RFC6151</em> <a href="#RFC6151"><b>14.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li> … … 5202 5203 </li> 5203 5204 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 5204 <li>safe <a href="#rfc.iref.s.1"><b>3. 1.1</b></a></li>5205 <li>safe <a href="#rfc.iref.s.1"><b>3.2.1</b></a></li> 5205 5206 <li>selected representation <a href="#rfc.iref.s.43"><b>8.2</b></a></li> 5206 5207 <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> … … 5254 5255 </ul> 5255 5256 </li> 5257 <li><em>status-308</em> <a href="#rfc.xref.status-308.1">5.5.7</a>, <a href="#status-308"><b>14.2</b></a></li> 5256 5258 </ul> 5257 5259 </li> 5258 5260 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 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>5261 <li>TRACE method <a href="#rfc.xref.TRACE.1">3.1</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.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5260 5262 </ul> 5261 5263 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1840 r1842 289 289 290 290 <section title="Request Methods" anchor="methods"> 291 292 <section title="Overview" anchor="method.overview"> 291 293 <x:anchor-alias value="method"/> 292 294 <t> … … 322 324 standardized methods are defined in all-uppercase ASCII letters. 323 325 </t> 324 <texttable align="left" suppress-title="true" anchor=" method.overview">326 <texttable align="left" suppress-title="true" anchor="table.of.methods"> 325 327 <ttcol>Method</ttcol> 326 328 <ttcol>Description</ttcol> … … 375 377 with the <x:ref>405 (Method Not Allowed)</x:ref> status code. 376 378 </t> 379 </section> 380 377 381 <section title="Common Method Properties" anchor="method.properties"> 378 382 … … 451 455 able to read the server's response. For example, if a client sends a PUT 452 456 request and the underlying connection is closed before any response is 453 received, then it can establish a new connection and retry the request454 because it knows that repeating the request will have the same effect455 e ven if the original request succeeded. Note, however, that repeated456 failures would indicate a problem within the server.457 received, then it can establish a new connection and retry the idempotent 458 request because it knows that repeating the request will have the same 459 effect even if the original request succeeded. Note, however, that 460 repeated failures would indicate a problem within the server. 457 461 </t> 458 462 </section> … … 466 470 request. GET and HEAD are defined to be cacheable. In general, safe 467 471 methods that do not depend on a current or authoritative response are 468 alsocacheable, though the overwhelming majority of caches only support472 cacheable, though the overwhelming majority of caches only support 469 473 GET and HEAD. HTTP requirements for cache behavior and cacheable responses 470 474 are defined in &caching;. … … 1784 1788 that it does not allow rewriting the request method from POST to GET. This 1785 1789 specification defines no equivalent counterpart for <x:ref>301 (Moved 1786 Permanently)</x:ref> (<xref target=" draft-reschke-http-status-308"/>,1790 Permanently)</x:ref> (<xref target="status-308"/>, 1787 1791 however, defines the status code 308 (Permanent Redirect) for this purpose). 1788 1792 </t> … … 5025 5029 <references title="Informative References"> 5026 5030 5027 <reference anchor="REST" target="http:// www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">5031 <reference anchor="REST" target="http://roy.gbiv.com/pubs/dissertation/top.htm"> 5028 5032 <front> 5029 5033 <title>Architectural Styles and the Design of Network-based Software Architectures</title> 5030 5034 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 5031 <organization>Doctoral Dissertation, University of California, Irvine</organization> 5032 </author> 5033 <date month="Sep" year="2000"/> 5035 </author> 5036 <date month="September" year="2000"/> 5034 5037 </front> 5038 <seriesInfo name='Doctoral Dissertation, University of California, Irvine' value=''/> 5035 5039 </reference> 5036 5040 … … 5383 5387 </reference> 5384 5388 5385 <reference anchor=" draft-reschke-http-status-308">5389 <reference anchor="status-308"> 5386 5390 <front> 5387 5391 <title abbrev="HTTP Status Code 308">The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)</title>
Note: See TracChangeset
for help on using the changeset viewer.