| 760 | | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
| 761 | | <p id="rfc.section.1.p.1">This document defines HTTP/1.1 request and response semantics. Each HTTP message, as defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, is in the form of either a request or a response. An HTTP server listens on a connection for HTTP requests and responds |
| 762 | | to each request, in the order received on that connection, with one or more HTTP response messages. This document defines |
| 763 | | the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various |
| 764 | | response messages that might be expected as a result of applying that method to the target resource. |
| 765 | | </p> |
| 766 | | <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller |
| 767 | | errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will |
| 768 | | be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods, |
| 769 | | request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess |
| 770 | | reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. |
| 771 | | </p> |
| 772 | | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
| 773 | | <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" |
| 774 | | in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. |
| 775 | | </p> |
| 776 | | <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, |
| 777 | | Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. |
| 778 | | </p> |
| 779 | | <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that |
| 780 | | SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| 781 | | </p> |
| 782 | | <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. |
| 783 | | </p> |
| 784 | | <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling |
| 785 | | mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require |
| 786 | | different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the |
| 787 | | Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of |
| 788 | | error recovery could lead to dangerous consequences. |
| 789 | | </p> |
| 790 | | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> |
| 791 | | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. |
| 792 | | </p> |
| 793 | | <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG |
| 794 | | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| 795 | | (any visible US-ASCII character). |
| 796 | | </p> |
| 797 | | <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> |
| 798 | | <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: |
| 799 | | </p> |
| 800 | | <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> |
| | 767 | <div id="introduction"> |
| | 768 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> |
| | 769 | <p id="rfc.section.1.p.1">This document defines HTTP/1.1 request and response semantics. Each HTTP message, as defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, is in the form of either a request or a response. An HTTP server listens on a connection for HTTP requests and responds |
| | 770 | to each request, in the order received on that connection, with one or more HTTP response messages. This document defines |
| | 771 | the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various |
| | 772 | response messages that might be expected as a result of applying that method to the target resource. |
| | 773 | </p> |
| | 774 | <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller |
| | 775 | errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will |
| | 776 | be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods, |
| | 777 | request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess |
| | 778 | reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. |
| | 779 | </p> |
| | 780 | <div id="intro.conformance.and.error.handling"> |
| | 781 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
| | 782 | <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" |
| | 783 | in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. |
| | 784 | </p> |
| | 785 | <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, |
| | 786 | Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. |
| | 787 | </p> |
| | 788 | <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that |
| | 789 | SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
| | 790 | </p> |
| | 791 | <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. |
| | 792 | </p> |
| | 793 | <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling |
| | 794 | mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require |
| | 795 | different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the |
| | 796 | Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of |
| | 797 | error recovery could lead to dangerous consequences. |
| | 798 | </p> |
| | 799 | </div> |
| | 800 | <div id="notation"> |
| | 801 | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a href="#notation">Syntax Notation</a></h2> |
| | 802 | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. |
| | 803 | </p> |
| | 804 | <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG |
| | 805 | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
| | 806 | (any visible US-ASCII character). |
| | 807 | </p> |
| | 808 | <div id="core.rules"> |
| | 809 | <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a href="#core.rules">Core Rules</a></h3> |
| | 810 | <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: |
| | 811 | </p> |
| | 812 | <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> |
| 923 | | double quotes will likely cause unnecessary confusion. |
| 924 | | </p> |
| 925 | | <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing |
| 926 | | parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for |
| 927 | | it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| 928 | | </p> |
| 929 | | <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p> |
| 930 | | <ul> |
| 931 | | <li> |
| 932 | | <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| 933 | | </p> |
| 934 | | <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible |
| 935 | | default would be to ignore the header field, but this might not always be the right choice). |
| 936 | | </p> |
| 937 | | <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the |
| 938 | | header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type", |
| 939 | | as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI). |
| 940 | | </p> |
| 941 | | </li> |
| 942 | | <li> |
| 943 | | <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses |
| 944 | | to a particular request method. |
| 945 | | </p> |
| 946 | | </li> |
| 947 | | <li> |
| 948 | | <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| 949 | | </p> |
| 950 | | </li> |
| 951 | | <li> |
| 952 | | <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p> |
| 953 | | </li> |
| 954 | | <li> |
| 955 | | <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 956 | | </p> |
| 957 | | </li> |
| 958 | | <li> |
| 959 | | <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| 960 | | </p> |
| 961 | | </li> |
| 962 | | <li> |
| 963 | | <p>Whether the header field should be preserved across redirects.</p> |
| 964 | | </li> |
| 965 | | </ul> |
| 966 | | <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2> |
| 967 | | <p id="rfc.section.3.2.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, |
| 968 | | to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language |
| 969 | | method invocation. |
| 970 | | </p> |
| 971 | | <div id="rfc.table.u.2"> |
| 972 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 973 | | <thead> |
| 974 | | <tr> |
| 975 | | <th>Header Field Name</th> |
| 976 | | <th>Defined in...</th> |
| 977 | | </tr> |
| 978 | | </thead> |
| 979 | | <tbody> |
| 980 | | <tr> |
| 981 | | <td class="left">Accept</td> |
| 982 | | <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| 983 | | </tr> |
| 984 | | <tr> |
| 985 | | <td class="left">Accept-Charset</td> |
| 986 | | <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| 987 | | </tr> |
| 988 | | <tr> |
| 989 | | <td class="left">Accept-Encoding</td> |
| 990 | | <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| 991 | | </tr> |
| 992 | | <tr> |
| 993 | | <td class="left">Accept-Language</td> |
| 994 | | <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| 995 | | </tr> |
| 996 | | <tr> |
| 997 | | <td class="left">Authorization</td> |
| 998 | | <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| 999 | | </tr> |
| 1000 | | <tr> |
| 1001 | | <td class="left">Expect</td> |
| 1002 | | <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.3</a></td> |
| 1003 | | </tr> |
| 1004 | | <tr> |
| 1005 | | <td class="left">From</td> |
| 1006 | | <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.4</a></td> |
| 1007 | | </tr> |
| 1008 | | <tr> |
| 1009 | | <td class="left">Host</td> |
| 1010 | | <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
| 1011 | | </tr> |
| 1012 | | <tr> |
| 1013 | | <td class="left">If-Match</td> |
| 1014 | | <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1015 | | </tr> |
| 1016 | | <tr> |
| 1017 | | <td class="left">If-Modified-Since</td> |
| 1018 | | <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1019 | | </tr> |
| 1020 | | <tr> |
| 1021 | | <td class="left">If-None-Match</td> |
| 1022 | | <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1023 | | </tr> |
| 1024 | | <tr> |
| 1025 | | <td class="left">If-Range</td> |
| 1026 | | <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| 1027 | | </tr> |
| 1028 | | <tr> |
| 1029 | | <td class="left">If-Unmodified-Since</td> |
| 1030 | | <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1031 | | </tr> |
| 1032 | | <tr> |
| 1033 | | <td class="left">Max-Forwards</td> |
| 1034 | | <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.6</a></td> |
| 1035 | | </tr> |
| 1036 | | <tr> |
| 1037 | | <td class="left">Proxy-Authorization</td> |
| 1038 | | <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| 1039 | | </tr> |
| 1040 | | <tr> |
| 1041 | | <td class="left">Range</td> |
| 1042 | | <td class="left"><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 and Partial Responses">[Part5]</cite></a></td> |
| 1043 | | </tr> |
| 1044 | | <tr> |
| 1045 | | <td class="left">Referer</td> |
| 1046 | | <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.7</a></td> |
| 1047 | | </tr> |
| 1048 | | <tr> |
| 1049 | | <td class="left">TE</td> |
| 1050 | | <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
| 1051 | | </tr> |
| 1052 | | <tr> |
| 1053 | | <td class="left">User-Agent</td> |
| 1054 | | <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.10</a></td> |
| 1055 | | </tr> |
| 1056 | | </tbody> |
| 1057 | | </table> |
| | 950 | double quotes will likely cause unnecessary confusion. |
| | 951 | </p> |
| | 952 | <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing |
| | 953 | parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for |
| | 954 | it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| | 955 | </p> |
| | 956 | <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p> |
| | 957 | <ul> |
| | 958 | <li> |
| | 959 | <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| | 960 | </p> |
| | 961 | <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible |
| | 962 | default would be to ignore the header field, but this might not always be the right choice). |
| | 963 | </p> |
| | 964 | <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the |
| | 965 | header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type", |
| | 966 | as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI). |
| | 967 | </p> |
| | 968 | </li> |
| | 969 | <li> |
| | 970 | <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses |
| | 971 | to a particular request method. |
| | 972 | </p> |
| | 973 | </li> |
| | 974 | <li> |
| | 975 | <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| | 976 | </p> |
| | 977 | </li> |
| | 978 | <li> |
| | 979 | <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p> |
| | 980 | </li> |
| | 981 | <li> |
| | 982 | <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 983 | </p> |
| | 984 | </li> |
| | 985 | <li> |
| | 986 | <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| | 987 | </p> |
| | 988 | </li> |
| | 989 | <li> |
| | 990 | <p>Whether the header field should be preserved across redirects.</p> |
| | 991 | </li> |
| | 992 | </ul> |
| | 993 | </div> |
| | 994 | <div id="request.header.fields"> |
| | 995 | <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a href="#request.header.fields">Request Header Fields</a></h2> |
| | 996 | <p id="rfc.section.3.2.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, |
| | 997 | to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language |
| | 998 | method invocation. |
| | 999 | </p> |
| | 1000 | <div id="rfc.table.u.2"> |
| | 1001 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 1002 | <thead> |
| | 1003 | <tr> |
| | 1004 | <th>Header Field Name</th> |
| | 1005 | <th>Defined in...</th> |
| | 1006 | </tr> |
| | 1007 | </thead> |
| | 1008 | <tbody> |
| | 1009 | <tr> |
| | 1010 | <td class="left">Accept</td> |
| | 1011 | <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| | 1012 | </tr> |
| | 1013 | <tr> |
| | 1014 | <td class="left">Accept-Charset</td> |
| | 1015 | <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| | 1016 | </tr> |
| | 1017 | <tr> |
| | 1018 | <td class="left">Accept-Encoding</td> |
| | 1019 | <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| | 1020 | </tr> |
| | 1021 | <tr> |
| | 1022 | <td class="left">Accept-Language</td> |
| | 1023 | <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
| | 1024 | </tr> |
| | 1025 | <tr> |
| | 1026 | <td class="left">Authorization</td> |
| | 1027 | <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1028 | </tr> |
| | 1029 | <tr> |
| | 1030 | <td class="left">Expect</td> |
| | 1031 | <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.3</a></td> |
| | 1032 | </tr> |
| | 1033 | <tr> |
| | 1034 | <td class="left">From</td> |
| | 1035 | <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.4</a></td> |
| | 1036 | </tr> |
| | 1037 | <tr> |
| | 1038 | <td class="left">Host</td> |
| | 1039 | <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
| | 1040 | </tr> |
| | 1041 | <tr> |
| | 1042 | <td class="left">If-Match</td> |
| | 1043 | <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1044 | </tr> |
| | 1045 | <tr> |
| | 1046 | <td class="left">If-Modified-Since</td> |
| | 1047 | <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1048 | </tr> |
| | 1049 | <tr> |
| | 1050 | <td class="left">If-None-Match</td> |
| | 1051 | <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1052 | </tr> |
| | 1053 | <tr> |
| | 1054 | <td class="left">If-Range</td> |
| | 1055 | <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| | 1056 | </tr> |
| | 1057 | <tr> |
| | 1058 | <td class="left">If-Unmodified-Since</td> |
| | 1059 | <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1060 | </tr> |
| | 1061 | <tr> |
| | 1062 | <td class="left">Max-Forwards</td> |
| | 1063 | <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.6</a></td> |
| | 1064 | </tr> |
| | 1065 | <tr> |
| | 1066 | <td class="left">Proxy-Authorization</td> |
| | 1067 | <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1068 | </tr> |
| | 1069 | <tr> |
| | 1070 | <td class="left">Range</td> |
| | 1071 | <td class="left"><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 and Partial Responses">[Part5]</cite></a></td> |
| | 1072 | </tr> |
| | 1073 | <tr> |
| | 1074 | <td class="left">Referer</td> |
| | 1075 | <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.7</a></td> |
| | 1076 | </tr> |
| | 1077 | <tr> |
| | 1078 | <td class="left">TE</td> |
| | 1079 | <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
| | 1080 | </tr> |
| | 1081 | <tr> |
| | 1082 | <td class="left">User-Agent</td> |
| | 1083 | <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.10</a></td> |
| | 1084 | </tr> |
| | 1085 | </tbody> |
| | 1086 | </table> |
| | 1087 | </div> |
| | 1088 | </div> |
| | 1089 | <div id="response.header.fields"> |
| | 1090 | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a href="#response.header.fields">Response Header Fields</a></h2> |
| | 1091 | <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the |
| | 1092 | status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
| | 1093 | </p> |
| | 1094 | <div id="rfc.table.u.3"> |
| | 1095 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 1096 | <thead> |
| | 1097 | <tr> |
| | 1098 | <th>Header Field Name</th> |
| | 1099 | <th>Defined in...</th> |
| | 1100 | </tr> |
| | 1101 | </thead> |
| | 1102 | <tbody> |
| | 1103 | <tr> |
| | 1104 | <td class="left">Accept-Ranges</td> |
| | 1105 | <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| | 1106 | </tr> |
| | 1107 | <tr> |
| | 1108 | <td class="left">Age</td> |
| | 1109 | <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> |
| | 1110 | </tr> |
| | 1111 | <tr> |
| | 1112 | <td class="left">Allow</td> |
| | 1113 | <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 10.1</a></td> |
| | 1114 | </tr> |
| | 1115 | <tr> |
| | 1116 | <td class="left">Date</td> |
| | 1117 | <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 10.2</a></td> |
| | 1118 | </tr> |
| | 1119 | <tr> |
| | 1120 | <td class="left">ETag</td> |
| | 1121 | <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1122 | </tr> |
| | 1123 | <tr> |
| | 1124 | <td class="left">Location</td> |
| | 1125 | <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.5</a></td> |
| | 1126 | </tr> |
| | 1127 | <tr> |
| | 1128 | <td class="left">Proxy-Authenticate</td> |
| | 1129 | <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1130 | </tr> |
| | 1131 | <tr> |
| | 1132 | <td class="left">Retry-After</td> |
| | 1133 | <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.8</a></td> |
| | 1134 | </tr> |
| | 1135 | <tr> |
| | 1136 | <td class="left">Server</td> |
| | 1137 | <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.9</a></td> |
| | 1138 | </tr> |
| | 1139 | <tr> |
| | 1140 | <td class="left">Vary</td> |
| | 1141 | <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> |
| | 1142 | </tr> |
| | 1143 | <tr> |
| | 1144 | <td class="left">WWW-Authenticate</td> |
| | 1145 | <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1146 | </tr> |
| | 1147 | </tbody> |
| | 1148 | </table> |
| | 1149 | </div> |
| | 1150 | </div> |
| 1127 | | though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent |
| 1128 | | to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was |
| 1129 | | something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the representation enclosed with the response, since that representation is likely to include human-readable |
| 1130 | | information which will explain the unusual status. |
| 1131 | | </p> |
| 1132 | | <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> |
| 1133 | | <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the |
| 1134 | | protocol. |
| 1135 | | </p> |
| 1136 | | <div id="rfc.table.u.4"> |
| 1137 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| 1138 | | <thead> |
| 1139 | | <tr> |
| 1140 | | <th>status-code</th> |
| 1141 | | <th>reason-phrase</th> |
| 1142 | | <th>Defined in...</th> |
| 1143 | | </tr> |
| 1144 | | </thead> |
| 1145 | | <tbody> |
| 1146 | | <tr> |
| 1147 | | <td class="left">100</td> |
| 1148 | | <td class="left">Continue</td> |
| 1149 | | <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a></td> |
| 1150 | | </tr> |
| 1151 | | <tr> |
| 1152 | | <td class="left">101</td> |
| 1153 | | <td class="left">Switching Protocols</td> |
| 1154 | | <td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a></td> |
| 1155 | | </tr> |
| 1156 | | <tr> |
| 1157 | | <td class="left">200</td> |
| 1158 | | <td class="left">OK</td> |
| 1159 | | <td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a></td> |
| 1160 | | </tr> |
| 1161 | | <tr> |
| 1162 | | <td class="left">201</td> |
| 1163 | | <td class="left">Created</td> |
| 1164 | | <td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 7.2.2</a></td> |
| 1165 | | </tr> |
| 1166 | | <tr> |
| 1167 | | <td class="left">202</td> |
| 1168 | | <td class="left">Accepted</td> |
| 1169 | | <td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 7.2.3</a></td> |
| 1170 | | </tr> |
| 1171 | | <tr> |
| 1172 | | <td class="left">203</td> |
| 1173 | | <td class="left">Non-Authoritative Information</td> |
| 1174 | | <td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 7.2.4</a></td> |
| 1175 | | </tr> |
| 1176 | | <tr> |
| 1177 | | <td class="left">204</td> |
| 1178 | | <td class="left">No Content</td> |
| 1179 | | <td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 7.2.5</a></td> |
| 1180 | | </tr> |
| 1181 | | <tr> |
| 1182 | | <td class="left">205</td> |
| 1183 | | <td class="left">Reset Content</td> |
| 1184 | | <td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 7.2.6</a></td> |
| 1185 | | </tr> |
| 1186 | | <tr> |
| 1187 | | <td class="left">206</td> |
| 1188 | | <td class="left">Partial Content</td> |
| 1189 | | <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| 1190 | | </tr> |
| 1191 | | <tr> |
| 1192 | | <td class="left">300</td> |
| 1193 | | <td class="left">Multiple Choices</td> |
| 1194 | | <td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 7.3.1</a></td> |
| 1195 | | </tr> |
| 1196 | | <tr> |
| 1197 | | <td class="left">301</td> |
| 1198 | | <td class="left">Moved Permanently</td> |
| 1199 | | <td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 7.3.2</a></td> |
| 1200 | | </tr> |
| 1201 | | <tr> |
| 1202 | | <td class="left">302</td> |
| 1203 | | <td class="left">Found</td> |
| 1204 | | <td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 7.3.3</a></td> |
| 1205 | | </tr> |
| 1206 | | <tr> |
| 1207 | | <td class="left">303</td> |
| 1208 | | <td class="left">See Other</td> |
| 1209 | | <td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 7.3.4</a></td> |
| 1210 | | </tr> |
| 1211 | | <tr> |
| 1212 | | <td class="left">304</td> |
| 1213 | | <td class="left">Not Modified</td> |
| 1214 | | <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1215 | | </tr> |
| 1216 | | <tr> |
| 1217 | | <td class="left">305</td> |
| 1218 | | <td class="left">Use Proxy</td> |
| 1219 | | <td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 7.3.5</a></td> |
| 1220 | | </tr> |
| 1221 | | <tr> |
| 1222 | | <td class="left">307</td> |
| 1223 | | <td class="left">Temporary Redirect</td> |
| 1224 | | <td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 7.3.7</a></td> |
| 1225 | | </tr> |
| 1226 | | <tr> |
| 1227 | | <td class="left">400</td> |
| 1228 | | <td class="left">Bad Request</td> |
| 1229 | | <td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 7.4.1</a></td> |
| 1230 | | </tr> |
| 1231 | | <tr> |
| 1232 | | <td class="left">401</td> |
| 1233 | | <td class="left">Unauthorized</td> |
| 1234 | | <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| 1235 | | </tr> |
| 1236 | | <tr> |
| 1237 | | <td class="left">402</td> |
| 1238 | | <td class="left">Payment Required</td> |
| 1239 | | <td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 7.4.2</a></td> |
| 1240 | | </tr> |
| 1241 | | <tr> |
| 1242 | | <td class="left">403</td> |
| 1243 | | <td class="left">Forbidden</td> |
| 1244 | | <td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 7.4.3</a></td> |
| 1245 | | </tr> |
| 1246 | | <tr> |
| 1247 | | <td class="left">404</td> |
| 1248 | | <td class="left">Not Found</td> |
| 1249 | | <td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 7.4.4</a></td> |
| 1250 | | </tr> |
| 1251 | | <tr> |
| 1252 | | <td class="left">405</td> |
| 1253 | | <td class="left">Method Not Allowed</td> |
| 1254 | | <td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 7.4.5</a></td> |
| 1255 | | </tr> |
| 1256 | | <tr> |
| 1257 | | <td class="left">406</td> |
| 1258 | | <td class="left">Not Acceptable</td> |
| 1259 | | <td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 7.4.6</a></td> |
| 1260 | | </tr> |
| 1261 | | <tr> |
| 1262 | | <td class="left">407</td> |
| 1263 | | <td class="left">Proxy Authentication Required</td> |
| 1264 | | <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| 1265 | | </tr> |
| 1266 | | <tr> |
| 1267 | | <td class="left">408</td> |
| 1268 | | <td class="left">Request Time-out</td> |
| 1269 | | <td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 7.4.7</a></td> |
| 1270 | | </tr> |
| 1271 | | <tr> |
| 1272 | | <td class="left">409</td> |
| 1273 | | <td class="left">Conflict</td> |
| 1274 | | <td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 7.4.8</a></td> |
| 1275 | | </tr> |
| 1276 | | <tr> |
| 1277 | | <td class="left">410</td> |
| 1278 | | <td class="left">Gone</td> |
| 1279 | | <td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 7.4.9</a></td> |
| 1280 | | </tr> |
| 1281 | | <tr> |
| 1282 | | <td class="left">411</td> |
| 1283 | | <td class="left">Length Required</td> |
| 1284 | | <td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 7.4.10</a></td> |
| 1285 | | </tr> |
| 1286 | | <tr> |
| 1287 | | <td class="left">412</td> |
| 1288 | | <td class="left">Precondition Failed</td> |
| 1289 | | <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| 1290 | | </tr> |
| 1291 | | <tr> |
| 1292 | | <td class="left">413</td> |
| 1293 | | <td class="left">Request Representation Too Large</td> |
| 1294 | | <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section 7.4.11</a></td> |
| 1295 | | </tr> |
| 1296 | | <tr> |
| 1297 | | <td class="left">414</td> |
| 1298 | | <td class="left">URI Too Long</td> |
| 1299 | | <td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 7.4.12</a></td> |
| 1300 | | </tr> |
| 1301 | | <tr> |
| 1302 | | <td class="left">415</td> |
| 1303 | | <td class="left">Unsupported Media Type</td> |
| 1304 | | <td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 7.4.13</a></td> |
| 1305 | | </tr> |
| 1306 | | <tr> |
| 1307 | | <td class="left">416</td> |
| 1308 | | <td class="left">Requested range not satisfiable</td> |
| 1309 | | <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| 1310 | | </tr> |
| 1311 | | <tr> |
| 1312 | | <td class="left">417</td> |
| 1313 | | <td class="left">Expectation Failed</td> |
| 1314 | | <td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 7.4.14</a></td> |
| 1315 | | </tr> |
| 1316 | | <tr> |
| 1317 | | <td class="left">426</td> |
| 1318 | | <td class="left">Upgrade Required</td> |
| 1319 | | <td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section 7.4.15</a></td> |
| 1320 | | </tr> |
| 1321 | | <tr> |
| 1322 | | <td class="left">500</td> |
| 1323 | | <td class="left">Internal Server Error</td> |
| 1324 | | <td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 7.5.1</a></td> |
| 1325 | | </tr> |
| 1326 | | <tr> |
| 1327 | | <td class="left">501</td> |
| 1328 | | <td class="left">Not Implemented</td> |
| 1329 | | <td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 7.5.2</a></td> |
| 1330 | | </tr> |
| 1331 | | <tr> |
| 1332 | | <td class="left">502</td> |
| 1333 | | <td class="left">Bad Gateway</td> |
| 1334 | | <td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 7.5.3</a></td> |
| 1335 | | </tr> |
| 1336 | | <tr> |
| 1337 | | <td class="left">503</td> |
| 1338 | | <td class="left">Service Unavailable</td> |
| 1339 | | <td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 7.5.4</a></td> |
| 1340 | | </tr> |
| 1341 | | <tr> |
| 1342 | | <td class="left">504</td> |
| 1343 | | <td class="left">Gateway Time-out</td> |
| 1344 | | <td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 7.5.5</a></td> |
| 1345 | | </tr> |
| 1346 | | <tr> |
| 1347 | | <td class="left">505</td> |
| 1348 | | <td class="left">HTTP Version not supported</td> |
| 1349 | | <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 7.5.6</a></td> |
| 1350 | | </tr> |
| 1351 | | </tbody> |
| 1352 | | </table> |
| | 1161 | though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent |
| | 1162 | to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was |
| | 1163 | something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the representation enclosed with the response, since that representation is likely to include human-readable |
| | 1164 | information which will explain the unusual status. |
| | 1165 | </p> |
| | 1166 | <div id="overview.of.status.codes"> |
| | 1167 | <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a href="#overview.of.status.codes">Overview of Status Codes</a></h2> |
| | 1168 | <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the |
| | 1169 | protocol. |
| | 1170 | </p> |
| | 1171 | <div id="rfc.table.u.4"> |
| | 1172 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
| | 1173 | <thead> |
| | 1174 | <tr> |
| | 1175 | <th>status-code</th> |
| | 1176 | <th>reason-phrase</th> |
| | 1177 | <th>Defined in...</th> |
| | 1178 | </tr> |
| | 1179 | </thead> |
| | 1180 | <tbody> |
| | 1181 | <tr> |
| | 1182 | <td class="left">100</td> |
| | 1183 | <td class="left">Continue</td> |
| | 1184 | <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a></td> |
| | 1185 | </tr> |
| | 1186 | <tr> |
| | 1187 | <td class="left">101</td> |
| | 1188 | <td class="left">Switching Protocols</td> |
| | 1189 | <td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a></td> |
| | 1190 | </tr> |
| | 1191 | <tr> |
| | 1192 | <td class="left">200</td> |
| | 1193 | <td class="left">OK</td> |
| | 1194 | <td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a></td> |
| | 1195 | </tr> |
| | 1196 | <tr> |
| | 1197 | <td class="left">201</td> |
| | 1198 | <td class="left">Created</td> |
| | 1199 | <td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 7.2.2</a></td> |
| | 1200 | </tr> |
| | 1201 | <tr> |
| | 1202 | <td class="left">202</td> |
| | 1203 | <td class="left">Accepted</td> |
| | 1204 | <td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 7.2.3</a></td> |
| | 1205 | </tr> |
| | 1206 | <tr> |
| | 1207 | <td class="left">203</td> |
| | 1208 | <td class="left">Non-Authoritative Information</td> |
| | 1209 | <td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 7.2.4</a></td> |
| | 1210 | </tr> |
| | 1211 | <tr> |
| | 1212 | <td class="left">204</td> |
| | 1213 | <td class="left">No Content</td> |
| | 1214 | <td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 7.2.5</a></td> |
| | 1215 | </tr> |
| | 1216 | <tr> |
| | 1217 | <td class="left">205</td> |
| | 1218 | <td class="left">Reset Content</td> |
| | 1219 | <td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 7.2.6</a></td> |
| | 1220 | </tr> |
| | 1221 | <tr> |
| | 1222 | <td class="left">206</td> |
| | 1223 | <td class="left">Partial Content</td> |
| | 1224 | <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| | 1225 | </tr> |
| | 1226 | <tr> |
| | 1227 | <td class="left">300</td> |
| | 1228 | <td class="left">Multiple Choices</td> |
| | 1229 | <td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 7.3.1</a></td> |
| | 1230 | </tr> |
| | 1231 | <tr> |
| | 1232 | <td class="left">301</td> |
| | 1233 | <td class="left">Moved Permanently</td> |
| | 1234 | <td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 7.3.2</a></td> |
| | 1235 | </tr> |
| | 1236 | <tr> |
| | 1237 | <td class="left">302</td> |
| | 1238 | <td class="left">Found</td> |
| | 1239 | <td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 7.3.3</a></td> |
| | 1240 | </tr> |
| | 1241 | <tr> |
| | 1242 | <td class="left">303</td> |
| | 1243 | <td class="left">See Other</td> |
| | 1244 | <td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 7.3.4</a></td> |
| | 1245 | </tr> |
| | 1246 | <tr> |
| | 1247 | <td class="left">304</td> |
| | 1248 | <td class="left">Not Modified</td> |
| | 1249 | <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1250 | </tr> |
| | 1251 | <tr> |
| | 1252 | <td class="left">305</td> |
| | 1253 | <td class="left">Use Proxy</td> |
| | 1254 | <td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 7.3.5</a></td> |
| | 1255 | </tr> |
| | 1256 | <tr> |
| | 1257 | <td class="left">307</td> |
| | 1258 | <td class="left">Temporary Redirect</td> |
| | 1259 | <td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 7.3.7</a></td> |
| | 1260 | </tr> |
| | 1261 | <tr> |
| | 1262 | <td class="left">400</td> |
| | 1263 | <td class="left">Bad Request</td> |
| | 1264 | <td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 7.4.1</a></td> |
| | 1265 | </tr> |
| | 1266 | <tr> |
| | 1267 | <td class="left">401</td> |
| | 1268 | <td class="left">Unauthorized</td> |
| | 1269 | <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1270 | </tr> |
| | 1271 | <tr> |
| | 1272 | <td class="left">402</td> |
| | 1273 | <td class="left">Payment Required</td> |
| | 1274 | <td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 7.4.2</a></td> |
| | 1275 | </tr> |
| | 1276 | <tr> |
| | 1277 | <td class="left">403</td> |
| | 1278 | <td class="left">Forbidden</td> |
| | 1279 | <td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 7.4.3</a></td> |
| | 1280 | </tr> |
| | 1281 | <tr> |
| | 1282 | <td class="left">404</td> |
| | 1283 | <td class="left">Not Found</td> |
| | 1284 | <td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 7.4.4</a></td> |
| | 1285 | </tr> |
| | 1286 | <tr> |
| | 1287 | <td class="left">405</td> |
| | 1288 | <td class="left">Method Not Allowed</td> |
| | 1289 | <td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 7.4.5</a></td> |
| | 1290 | </tr> |
| | 1291 | <tr> |
| | 1292 | <td class="left">406</td> |
| | 1293 | <td class="left">Not Acceptable</td> |
| | 1294 | <td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 7.4.6</a></td> |
| | 1295 | </tr> |
| | 1296 | <tr> |
| | 1297 | <td class="left">407</td> |
| | 1298 | <td class="left">Proxy Authentication Required</td> |
| | 1299 | <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
| | 1300 | </tr> |
| | 1301 | <tr> |
| | 1302 | <td class="left">408</td> |
| | 1303 | <td class="left">Request Time-out</td> |
| | 1304 | <td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 7.4.7</a></td> |
| | 1305 | </tr> |
| | 1306 | <tr> |
| | 1307 | <td class="left">409</td> |
| | 1308 | <td class="left">Conflict</td> |
| | 1309 | <td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 7.4.8</a></td> |
| | 1310 | </tr> |
| | 1311 | <tr> |
| | 1312 | <td class="left">410</td> |
| | 1313 | <td class="left">Gone</td> |
| | 1314 | <td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 7.4.9</a></td> |
| | 1315 | </tr> |
| | 1316 | <tr> |
| | 1317 | <td class="left">411</td> |
| | 1318 | <td class="left">Length Required</td> |
| | 1319 | <td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 7.4.10</a></td> |
| | 1320 | </tr> |
| | 1321 | <tr> |
| | 1322 | <td class="left">412</td> |
| | 1323 | <td class="left">Precondition Failed</td> |
| | 1324 | <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
| | 1325 | </tr> |
| | 1326 | <tr> |
| | 1327 | <td class="left">413</td> |
| | 1328 | <td class="left">Request Representation Too Large</td> |
| | 1329 | <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section 7.4.11</a></td> |
| | 1330 | </tr> |
| | 1331 | <tr> |
| | 1332 | <td class="left">414</td> |
| | 1333 | <td class="left">URI Too Long</td> |
| | 1334 | <td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 7.4.12</a></td> |
| | 1335 | </tr> |
| | 1336 | <tr> |
| | 1337 | <td class="left">415</td> |
| | 1338 | <td class="left">Unsupported Media Type</td> |
| | 1339 | <td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 7.4.13</a></td> |
| | 1340 | </tr> |
| | 1341 | <tr> |
| | 1342 | <td class="left">416</td> |
| | 1343 | <td class="left">Requested range not satisfiable</td> |
| | 1344 | <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
| | 1345 | </tr> |
| | 1346 | <tr> |
| | 1347 | <td class="left">417</td> |
| | 1348 | <td class="left">Expectation Failed</td> |
| | 1349 | <td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 7.4.14</a></td> |
| | 1350 | </tr> |
| | 1351 | <tr> |
| | 1352 | <td class="left">426</td> |
| | 1353 | <td class="left">Upgrade Required</td> |
| | 1354 | <td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section 7.4.15</a></td> |
| | 1355 | </tr> |
| | 1356 | <tr> |
| | 1357 | <td class="left">500</td> |
| | 1358 | <td class="left">Internal Server Error</td> |
| | 1359 | <td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 7.5.1</a></td> |
| | 1360 | </tr> |
| | 1361 | <tr> |
| | 1362 | <td class="left">501</td> |
| | 1363 | <td class="left">Not Implemented</td> |
| | 1364 | <td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 7.5.2</a></td> |
| | 1365 | </tr> |
| | 1366 | <tr> |
| | 1367 | <td class="left">502</td> |
| | 1368 | <td class="left">Bad Gateway</td> |
| | 1369 | <td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 7.5.3</a></td> |
| | 1370 | </tr> |
| | 1371 | <tr> |
| | 1372 | <td class="left">503</td> |
| | 1373 | <td class="left">Service Unavailable</td> |
| | 1374 | <td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 7.5.4</a></td> |
| | 1375 | </tr> |
| | 1376 | <tr> |
| | 1377 | <td class="left">504</td> |
| | 1378 | <td class="left">Gateway Time-out</td> |
| | 1379 | <td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 7.5.5</a></td> |
| | 1380 | </tr> |
| | 1381 | <tr> |
| | 1382 | <td class="left">505</td> |
| | 1383 | <td class="left">HTTP Version not supported</td> |
| | 1384 | <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 7.5.6</a></td> |
| | 1385 | </tr> |
| | 1386 | </tbody> |
| | 1387 | </table> |
| | 1388 | </div> |
| | 1389 | <p id="rfc.section.4.1.p.2">Note that this list is not exhaustive — it does not include extension status codes defined in other specifications.</p> |
| | 1390 | </div> |
| | 1391 | <div id="status.code.registry"> |
| | 1392 | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a href="#status.code.registry">Status Code Registry</a></h2> |
| | 1393 | <p id="rfc.section.4.2.p.1">The HTTP Status Code Registry defines the name space for the status-code token in the status-line of an HTTP response.</p> |
| | 1394 | <p id="rfc.section.4.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). |
| | 1395 | </p> |
| | 1396 | <p id="rfc.section.4.2.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. |
| | 1397 | </p> |
| | 1398 | <div id="considerations.for.new.status.codes"> |
| | 1399 | <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> |
| | 1400 | <p id="rfc.section.4.2.1.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type, |
| | 1401 | and currently defined status codes are inadequate, a new status code can be registered. |
| | 1402 | </p> |
| | 1403 | <p id="rfc.section.4.2.1.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type, |
| | 1404 | "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't |
| | 1405 | specific to a single application, so that this is clear. |
| | 1406 | </p> |
| | 1407 | <p id="rfc.section.4.2.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status |
| | 1408 | code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those |
| | 1409 | that are required, those that modify the semantics of the response). |
| | 1410 | </p> |
| | 1411 | <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate |
| | 1412 | a zero-length response body. They can require the presence of one or more particular HTTP response header(s). |
| | 1413 | </p> |
| | 1414 | <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 5.1</a>; by default, it is anonymous). |
| | 1415 | </p> |
| | 1416 | </div> |
| | 1417 | </div> |
| 1354 | | <p id="rfc.section.4.1.p.2">Note that this list is not exhaustive — it does not include extension status codes defined in other specifications.</p> |
| 1355 | | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> |
| 1356 | | <p id="rfc.section.4.2.p.1">The HTTP Status Code Registry defines the name space for the status-code token in the status-line of an HTTP response.</p> |
| 1357 | | <p id="rfc.section.4.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). |
| 1358 | | </p> |
| 1359 | | <p id="rfc.section.4.2.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. |
| 1360 | | </p> |
| 1361 | | <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> |
| 1362 | | <p id="rfc.section.4.2.1.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type, |
| 1363 | | and currently defined status codes are inadequate, a new status code can be registered. |
| 1364 | | </p> |
| 1365 | | <p id="rfc.section.4.2.1.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type, |
| 1366 | | "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't |
| 1367 | | specific to a single application, so that this is clear. |
| 1368 | | </p> |
| 1369 | | <p id="rfc.section.4.2.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status |
| 1370 | | code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those |
| 1371 | | that are required, those that modify the semantics of the response). |
| 1372 | | </p> |
| 1373 | | <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate |
| 1374 | | a zero-length response body. They can require the presence of one or more particular HTTP response header(s). |
| 1375 | | </p> |
| 1376 | | <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 5.1</a>; by default, it is anonymous). |
| 1377 | | </p> |
| 1378 | | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> |
| 1379 | | <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists |
| 1380 | | of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed |
| 1381 | | in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. |
| 1382 | | </p> |
| 1383 | | <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied |
| 1384 | | to ensure safe and proper transfer of the message. |
| 1385 | | </p> |
| 1386 | | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> |
| 1387 | | <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> |
| 1388 | | <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> |
| 1389 | | <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following |
| 1390 | | rules are used (with the first applicable one being selected): |
| 1391 | | </p> |
| 1392 | | <ol> |
| 1393 | | <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the |
| 1394 | | target resource. |
| 1395 | | </li> |
| 1396 | | <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial |
| 1397 | | representation of the target resource. |
| 1398 | | </li> |
| 1399 | | <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload |
| 1400 | | is a representation of the target resource. |
| 1401 | | </li> |
| 1402 | | <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response |
| 1403 | | asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion |
| 1404 | | cannot be trusted unless it can be verified by other means (not defined by HTTP). |
| 1405 | | </li> |
| 1406 | | <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> |
| 1407 | | </ol> |
| 1408 | | <p id="rfc.section.5.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like |
| 1409 | | cache invalidation.]</span> |
| 1410 | | </p> |
| 1411 | | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> |
| 1412 | | <p id="rfc.section.6.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot |
| 1413 | | be assumed to share the same semantics for separately extended clients and servers. |
| 1414 | | </p> |
| 1415 | | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> |
| 1416 | | <div id="rfc.iref.s.1"></div> |
| 1417 | | <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> |
| 1418 | | <p id="rfc.section.6.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow |
| 1419 | | the user to be aware of any actions they take which might have an unexpected significance to themselves or others. |
| 1420 | | </p> |
| 1421 | | <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is |
| 1422 | | made aware of the fact that a possibly unsafe action is being requested. |
| 1423 | | </p> |
| 1424 | | <p id="rfc.section.6.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; |
| 1425 | | in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the |
| 1426 | | side-effects, so therefore cannot be held accountable for them. |
| 1427 | | </p> |
| 1428 | | <div id="rfc.iref.i.1"></div> |
| 1429 | | <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> |
| 1430 | | <p id="rfc.section.6.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect |
| 1431 | | of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. |
| 1432 | | It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state |
| 1433 | | due to multiple requests for the purpose of tracking those requests, versioning of results, etc. |
| 1434 | | </p> |
| 1435 | | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> |
| 1436 | | <div id="rfc.iref.o.1"></div> |
| 1437 | | <div id="rfc.iref.m.1"></div> |
| 1438 | | <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified |
| 1439 | | by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, |
| 1440 | | or the capabilities of a server, without implying a resource action or initiating a resource retrieval. |
| 1441 | | </p> |
| 1442 | | <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> |
| 1443 | | <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then |
| 1444 | | the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions |
| 1445 | | to HTTP might use the OPTIONS body to make more detailed queries on the server. |
| 1446 | | </p> |
| 1447 | | <p id="rfc.section.6.2.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.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. |
| 1448 | | Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" |
| 1449 | | type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be |
| 1450 | | used to test a proxy for HTTP/1.1 conformance (or lack thereof). |
| 1451 | | </p> |
| 1452 | | <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating |
| 1453 | | with that resource. |
| 1454 | | </p> |
| 1455 | | <p id="rfc.section.6.2.p.6">A 200 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., |
| 1456 | | Allow), 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, |
| 1457 | | 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 Content-Length field with a field-value of "0". |
| 1458 | | </p> |
| 1459 | | <p id="rfc.section.6.2.p.7">The Max-Forwards 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.2" title="Max-Forwards">Section 10.6</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. |
| 1460 | | </p> |
| 1461 | | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2> |
| 1462 | | <div id="rfc.iref.g.5"></div> |
| 1463 | | <div id="rfc.iref.m.2"></div> |
| 1464 | | <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> |
| 1465 | | <p id="rfc.section.6.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation |
| 1466 | | in the response and not the source text of the process, unless that text happens to be the output of the process. |
| 1467 | | </p> |
| 1468 | | <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, |
| 1469 | | If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only |
| 1470 | | under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary |
| 1471 | | network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data |
| 1472 | | already held by the client. |
| 1473 | | </p> |
| 1474 | | <p id="rfc.section.6.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial |
| 1475 | | 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.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations |
| 1476 | | to be completed without transferring data already held by the client. |
| 1477 | | </p> |
| 1478 | | <p id="rfc.section.6.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations |
| 1479 | | to reject the request. |
| 1480 | | </p> |
| 1481 | | <p id="rfc.section.6.3.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.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1482 | | </p> |
| 1483 | | <p id="rfc.section.6.3.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. |
| 1484 | | </p> |
| 1485 | | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> |
| 1486 | | <div id="rfc.iref.h.1"></div> |
| 1487 | | <div id="rfc.iref.m.3"></div> |
| 1488 | | <p id="rfc.section.6.4.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 |
| 1489 | | representation implied by the request without transferring the representation body. This method is often used for testing |
| 1490 | | hypertext links for validity, accessibility, and recent modification. |
| 1491 | | </p> |
| 1492 | | <p id="rfc.section.6.4.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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| 1493 | | </p> |
| 1494 | | <p id="rfc.section.6.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations |
| 1495 | | to reject the request. |
| 1496 | | </p> |
| 1497 | | <div id="rfc.iref.p.1"></div> |
| 1498 | | <div id="rfc.iref.m.4"></div> |
| 1499 | | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="POST" href="#POST">POST</a></h2> |
| 1500 | | <p id="rfc.section.6.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed |
| 1501 | | by the target resource. POST is designed to allow a uniform method to cover the following functions: |
| 1502 | | </p> |
| 1503 | | <ul> |
| 1504 | | <li>Annotation of existing resources;</li> |
| 1505 | | <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> |
| 1506 | | <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> |
| 1507 | | <li>Extending a database through an append operation.</li> |
| 1508 | | </ul> |
| 1509 | | <p id="rfc.section.6.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request |
| 1510 | | URI. |
| 1511 | | </p> |
| 1512 | | <p id="rfc.section.6.5.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 |
| 1513 | | 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a |
| 1514 | | representation that describes the result. |
| 1515 | | </p> |
| 1516 | | <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and |
| 1517 | | a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.5</a>). |
| 1518 | | </p> |
| 1519 | | <p id="rfc.section.6.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. |
| 1520 | | </p> |
| 1521 | | <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent |
| 1522 | | to retrieve a cacheable resource. |
| 1523 | | </p> |
| 1524 | | <div id="rfc.iref.p.2"></div> |
| 1525 | | <div id="rfc.iref.m.5"></div> |
| 1526 | | <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="PUT" href="#PUT">PUT</a></h2> |
| 1527 | | <p id="rfc.section.6.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation |
| 1528 | | enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on |
| 1529 | | that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there |
| 1530 | | is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents |
| 1531 | | in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful |
| 1532 | | response only implies that the user agent's intent was achieved at the time of its processing by the origin server. |
| 1533 | | </p> |
| 1534 | | <p id="rfc.section.6.6.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 201 (Created) response. If the target resource does have a current representation and that |
| 1535 | | representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) |
| 1536 | | or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. |
| 1537 | | </p> |
| 1538 | | <p id="rfc.section.6.6.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). |
| 1539 | | </p> |
| 1540 | | <p id="rfc.section.6.6.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 |
| 1541 | | or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information |
| 1542 | | related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent |
| 1543 | | with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an |
| 1544 | | appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) |
| 1545 | | or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type |
| 1546 | | values. |
| 1547 | | </p> |
| 1548 | | <p id="rfc.section.6.6.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being |
| 1549 | | PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format |
| 1550 | | consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response |
| 1551 | | indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would |
| 1552 | | be a suitable target for the new representation. |
| 1553 | | </p> |
| 1554 | | <p id="rfc.section.6.6.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 |
| 1555 | | of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in |
| 1556 | | any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how |
| 1557 | | such storage might change as a result of a change in resource state, nor how the origin server translates resource state into |
| 1558 | | representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by |
| 1559 | | the server. |
| 1560 | | </p> |
| 1561 | | <p id="rfc.section.6.6.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. |
| 1562 | | The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such |
| 1563 | | as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT |
| 1564 | | request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent |
| 1565 | | and visible to intermediaries, even though the exact effect is only known by the origin server. |
| 1566 | | </p> |
| 1567 | | <p id="rfc.section.6.6.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that |
| 1568 | | 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 |
| 1569 | | the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved |
| 1570 | | to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. |
| 1571 | | </p> |
| 1572 | | <p id="rfc.section.6.6.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) |
| 1573 | | which is separate from the URIs identifying each particular version (different resources that at one point shared the same |
| 1574 | | state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new |
| 1575 | | version resource in addition to changing the state of the target resource, and might also cause links to be added between |
| 1576 | | the related resources. |
| 1577 | | </p> |
| 1578 | | <p id="rfc.section.6.6.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or |
| 1579 | | might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting |
| 1580 | | a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method |
| 1581 | | that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). |
| 1582 | | </p> |
| 1583 | | <p id="rfc.section.6.6.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 |
| 1584 | | 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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1585 | | </p> |
| 1586 | | <div id="rfc.iref.d.1"></div> |
| 1587 | | <div id="rfc.iref.m.6"></div> |
| 1588 | | <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> |
| 1589 | | <p id="rfc.section.6.7.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 |
| 1590 | | has been carried out, even if the status code returned from the origin server indicates that the action has been completed |
| 1591 | | 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 |
| 1592 | | location. |
| 1593 | | </p> |
| 1594 | | <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been |
| 1595 | | enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. |
| 1596 | | </p> |
| 1597 | | <p id="rfc.section.6.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing |
| 1598 | | implementations to reject the request. |
| 1599 | | </p> |
| 1600 | | <p id="rfc.section.6.7.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 |
| 1601 | | 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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1602 | | </p> |
| 1603 | | <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> |
| 1604 | | <div id="rfc.iref.t.1"></div> |
| 1605 | | <div id="rfc.iref.m.7"></div> |
| 1606 | | <p id="rfc.section.6.8.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 200 (OK) response. The final recipient is either |
| 1607 | | the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. |
| 1608 | | </p> |
| 1609 | | <p id="rfc.section.6.8.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 |
| 1610 | | or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the |
| 1611 | | client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an |
| 1612 | | infinite loop. |
| 1613 | | </p> |
| 1614 | | <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type 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.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. |
| 1615 | | </p> |
| 1616 | | <div id="rfc.iref.c.1"></div> |
| 1617 | | <div id="rfc.iref.m.8"></div> |
| 1618 | | <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> |
| 1619 | | <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict |
| 1620 | | its behavior to blind forwarding of packets until the connection is closed. |
| 1621 | | </p> |
| 1622 | | <p id="rfc.section.6.9.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.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. |
| 1623 | | For example, |
| 1624 | | </p> |
| 1625 | | <div id="rfc.figure.u.6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 |
| | 1419 | <div id="representation"> |
| | 1420 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#representation">Representation</a></h1> |
| | 1421 | <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists |
| | 1422 | of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed |
| | 1423 | in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. |
| | 1424 | </p> |
| | 1425 | <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied |
| | 1426 | to ensure safe and proper transfer of the message. |
| | 1427 | </p> |
| | 1428 | <div id="identifying.response.associated.with.representation"> |
| | 1429 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> |
| | 1430 | <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> |
| | 1431 | <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> |
| | 1432 | <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following |
| | 1433 | rules are used (with the first applicable one being selected): |
| | 1434 | </p> |
| | 1435 | <ol> |
| | 1436 | <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the |
| | 1437 | target resource. |
| | 1438 | </li> |
| | 1439 | <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial |
| | 1440 | representation of the target resource. |
| | 1441 | </li> |
| | 1442 | <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload |
| | 1443 | is a representation of the target resource. |
| | 1444 | </li> |
| | 1445 | <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response |
| | 1446 | asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion |
| | 1447 | cannot be trusted unless it can be verified by other means (not defined by HTTP). |
| | 1448 | </li> |
| | 1449 | <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> |
| | 1450 | </ol> |
| | 1451 | <p id="rfc.section.5.1.p.5"><span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like |
| | 1452 | cache invalidation.]</span> |
| | 1453 | </p> |
| | 1454 | </div> |
| | 1455 | </div> |
| | 1456 | <div id="method.definitions"> |
| | 1457 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#method.definitions">Method Definitions</a></h1> |
| | 1458 | <p id="rfc.section.6.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot |
| | 1459 | be assumed to share the same semantics for separately extended clients and servers. |
| | 1460 | </p> |
| | 1461 | <div id="safe.and.idempotent"> |
| | 1462 | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> |
| | 1463 | <div id="safe.methods"> |
| | 1464 | <div id="rfc.iref.s.1"></div> |
| | 1465 | <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a href="#safe.methods">Safe Methods</a></h3> |
| | 1466 | <p id="rfc.section.6.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow |
| | 1467 | the user to be aware of any actions they take which might have an unexpected significance to themselves or others. |
| | 1468 | </p> |
| | 1469 | <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is |
| | 1470 | made aware of the fact that a possibly unsafe action is being requested. |
| | 1471 | </p> |
| | 1472 | <p id="rfc.section.6.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; |
| | 1473 | in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the |
| | 1474 | side-effects, so therefore cannot be held accountable for them. |
| | 1475 | </p> |
| | 1476 | </div> |
| | 1477 | <div id="idempotent.methods"> |
| | 1478 | <div id="rfc.iref.i.1"></div> |
| | 1479 | <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a href="#idempotent.methods">Idempotent Methods</a></h3> |
| | 1480 | <p id="rfc.section.6.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect |
| | 1481 | of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. |
| | 1482 | It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state |
| | 1483 | due to multiple requests for the purpose of tracking those requests, versioning of results, etc. |
| | 1484 | </p> |
| | 1485 | </div> |
| | 1486 | </div> |
| | 1487 | <div id="OPTIONS"> |
| | 1488 | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a href="#OPTIONS">OPTIONS</a></h2> |
| | 1489 | <div id="rfc.iref.o.1"></div> |
| | 1490 | <div id="rfc.iref.m.1"></div> |
| | 1491 | <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified |
| | 1492 | by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, |
| | 1493 | or the capabilities of a server, without implying a resource action or initiating a resource retrieval. |
| | 1494 | </p> |
| | 1495 | <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> |
| | 1496 | <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then |
| | 1497 | the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions |
| | 1498 | to HTTP might use the OPTIONS body to make more detailed queries on the server. |
| | 1499 | </p> |
| | 1500 | <p id="rfc.section.6.2.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.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. |
| | 1501 | Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" |
| | 1502 | type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be |
| | 1503 | used to test a proxy for HTTP/1.1 conformance (or lack thereof). |
| | 1504 | </p> |
| | 1505 | <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating |
| | 1506 | with that resource. |
| | 1507 | </p> |
| | 1508 | <p id="rfc.section.6.2.p.6">A 200 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., |
| | 1509 | Allow), 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, |
| | 1510 | 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 Content-Length field with a field-value of "0". |
| | 1511 | </p> |
| | 1512 | <p id="rfc.section.6.2.p.7">The Max-Forwards 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.2" title="Max-Forwards">Section 10.6</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. |
| | 1513 | </p> |
| | 1514 | </div> |
| | 1515 | <div id="GET"> |
| | 1516 | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a href="#GET">GET</a></h2> |
| | 1517 | <div id="rfc.iref.g.5"></div> |
| | 1518 | <div id="rfc.iref.m.2"></div> |
| | 1519 | <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> |
| | 1520 | <p id="rfc.section.6.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation |
| | 1521 | in the response and not the source text of the process, unless that text happens to be the output of the process. |
| | 1522 | </p> |
| | 1523 | <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, |
| | 1524 | If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only |
| | 1525 | under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary |
| | 1526 | network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data |
| | 1527 | already held by the client. |
| | 1528 | </p> |
| | 1529 | <p id="rfc.section.6.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial |
| | 1530 | 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.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations |
| | 1531 | to be completed without transferring data already held by the client. |
| | 1532 | </p> |
| | 1533 | <p id="rfc.section.6.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations |
| | 1534 | to reject the request. |
| | 1535 | </p> |
| | 1536 | <p id="rfc.section.6.3.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.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 1537 | </p> |
| | 1538 | <p id="rfc.section.6.3.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. |
| | 1539 | </p> |
| | 1540 | </div> |
| | 1541 | <div id="HEAD"> |
| | 1542 | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a href="#HEAD">HEAD</a></h2> |
| | 1543 | <div id="rfc.iref.h.1"></div> |
| | 1544 | <div id="rfc.iref.m.3"></div> |
| | 1545 | <p id="rfc.section.6.4.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 |
| | 1546 | representation implied by the request without transferring the representation body. This method is often used for testing |
| | 1547 | hypertext links for validity, accessibility, and recent modification. |
| | 1548 | </p> |
| | 1549 | <p id="rfc.section.6.4.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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
| | 1550 | </p> |
| | 1551 | <p id="rfc.section.6.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations |
| | 1552 | to reject the request. |
| | 1553 | </p> |
| | 1554 | </div> |
| | 1555 | <div id="POST"> |
| | 1556 | <div id="rfc.iref.p.1"></div> |
| | 1557 | <div id="rfc.iref.m.4"></div> |
| | 1558 | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a href="#POST">POST</a></h2> |
| | 1559 | <p id="rfc.section.6.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed |
| | 1560 | by the target resource. POST is designed to allow a uniform method to cover the following functions: |
| | 1561 | </p> |
| | 1562 | <ul> |
| | 1563 | <li>Annotation of existing resources;</li> |
| | 1564 | <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> |
| | 1565 | <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> |
| | 1566 | <li>Extending a database through an append operation.</li> |
| | 1567 | </ul> |
| | 1568 | <p id="rfc.section.6.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request |
| | 1569 | URI. |
| | 1570 | </p> |
| | 1571 | <p id="rfc.section.6.5.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 |
| | 1572 | 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a |
| | 1573 | representation that describes the result. |
| | 1574 | </p> |
| | 1575 | <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and |
| | 1576 | a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.5</a>). |
| | 1577 | </p> |
| | 1578 | <p id="rfc.section.6.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. |
| | 1579 | </p> |
| | 1580 | <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent |
| | 1581 | to retrieve a cacheable resource. |
| | 1582 | </p> |
| | 1583 | </div> |
| | 1584 | <div id="PUT"> |
| | 1585 | <div id="rfc.iref.p.2"></div> |
| | 1586 | <div id="rfc.iref.m.5"></div> |
| | 1587 | <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a href="#PUT">PUT</a></h2> |
| | 1588 | <p id="rfc.section.6.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation |
| | 1589 | enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on |
| | 1590 | that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there |
| | 1591 | is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents |
| | 1592 | in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful |
| | 1593 | response only implies that the user agent's intent was achieved at the time of its processing by the origin server. |
| | 1594 | </p> |
| | 1595 | <p id="rfc.section.6.6.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 201 (Created) response. If the target resource does have a current representation and that |
| | 1596 | representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) |
| | 1597 | or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. |
| | 1598 | </p> |
| | 1599 | <p id="rfc.section.6.6.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). |
| | 1600 | </p> |
| | 1601 | <p id="rfc.section.6.6.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 |
| | 1602 | or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information |
| | 1603 | related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent |
| | 1604 | with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an |
| | 1605 | appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) |
| | 1606 | or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type |
| | 1607 | values. |
| | 1608 | </p> |
| | 1609 | <p id="rfc.section.6.6.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being |
| | 1610 | PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format |
| | 1611 | consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response |
| | 1612 | indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would |
| | 1613 | be a suitable target for the new representation. |
| | 1614 | </p> |
| | 1615 | <p id="rfc.section.6.6.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 |
| | 1616 | of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in |
| | 1617 | any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how |
| | 1618 | such storage might change as a result of a change in resource state, nor how the origin server translates resource state into |
| | 1619 | representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by |
| | 1620 | the server. |
| | 1621 | </p> |
| | 1622 | <p id="rfc.section.6.6.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. |
| | 1623 | The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such |
| | 1624 | as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT |
| | 1625 | request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent |
| | 1626 | and visible to intermediaries, even though the exact effect is only known by the origin server. |
| | 1627 | </p> |
| | 1628 | <p id="rfc.section.6.6.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that |
| | 1629 | 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 |
| | 1630 | the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved |
| | 1631 | to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. |
| | 1632 | </p> |
| | 1633 | <p id="rfc.section.6.6.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) |
| | 1634 | which is separate from the URIs identifying each particular version (different resources that at one point shared the same |
| | 1635 | state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new |
| | 1636 | version resource in addition to changing the state of the target resource, and might also cause links to be added between |
| | 1637 | the related resources. |
| | 1638 | </p> |
| | 1639 | <p id="rfc.section.6.6.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or |
| | 1640 | might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting |
| | 1641 | a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method |
| | 1642 | that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). |
| | 1643 | </p> |
| | 1644 | <p id="rfc.section.6.6.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 |
| | 1645 | 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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 1646 | </p> |
| | 1647 | </div> |
| | 1648 | <div id="DELETE"> |
| | 1649 | <div id="rfc.iref.d.1"></div> |
| | 1650 | <div id="rfc.iref.m.6"></div> |
| | 1651 | <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a href="#DELETE">DELETE</a></h2> |
| | 1652 | <p id="rfc.section.6.7.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 |
| | 1653 | has been carried out, even if the status code returned from the origin server indicates that the action has been completed |
| | 1654 | 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 |
| | 1655 | location. |
| | 1656 | </p> |
| | 1657 | <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been |
| | 1658 | enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. |
| | 1659 | </p> |
| | 1660 | <p id="rfc.section.6.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing |
| | 1661 | implementations to reject the request. |
| | 1662 | </p> |
| | 1663 | <p id="rfc.section.6.7.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 |
| | 1664 | 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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 1665 | </p> |
| | 1666 | </div> |
| | 1667 | <div id="TRACE"> |
| | 1668 | <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a href="#TRACE">TRACE</a></h2> |
| | 1669 | <div id="rfc.iref.t.1"></div> |
| | 1670 | <div id="rfc.iref.m.7"></div> |
| | 1671 | <p id="rfc.section.6.8.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 200 (OK) response. The final recipient is either |
| | 1672 | the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. |
| | 1673 | </p> |
| | 1674 | <p id="rfc.section.6.8.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 |
| | 1675 | or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the |
| | 1676 | client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an |
| | 1677 | infinite loop. |
| | 1678 | </p> |
| | 1679 | <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type 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.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. |
| | 1680 | </p> |
| | 1681 | </div> |
| | 1682 | <div id="CONNECT"> |
| | 1683 | <div id="rfc.iref.c.1"></div> |
| | 1684 | <div id="rfc.iref.m.8"></div> |
| | 1685 | <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a href="#CONNECT">CONNECT</a></h2> |
| | 1686 | <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict |
| | 1687 | its behavior to blind forwarding of packets until the connection is closed. |
| | 1688 | </p> |
| | 1689 | <p id="rfc.section.6.9.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.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. |
| | 1690 | For example, |
| | 1691 | </p> |
| | 1692 | <div id="rfc.figure.u.6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 |
| 1641 | | to reject the request. |
| 1642 | | </p> |
| 1643 | | <p id="rfc.section.6.9.p.9">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 may be discarded |
| 1644 | | if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. |
| 1645 | | </p> |
| 1646 | | <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the |
| 1647 | | 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 2xx status code unless it has either a direct or tunnel connection established to the authority. |
| 1648 | | </p> |
| 1649 | | <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to |
| 1650 | | the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that |
| 1651 | | peer undelivered, that data will be discarded. |
| 1652 | | </p> |
| 1653 | | <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement |
| 1654 | | CONNECT. |
| 1655 | | </p> |
| 1656 | | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> |
| 1657 | | <p id="rfc.section.7.p.1">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. |
| 1658 | | There are 5 values for the first digit: |
| 1659 | | </p> |
| 1660 | | <ul> |
| 1661 | | <li>1xx: Informational - Request received, continuing process</li> |
| 1662 | | <li>2xx: Success - The action was successfully received, understood, and accepted</li> |
| 1663 | | <li>3xx: Redirection - Further action must be taken in order to complete the request</li> |
| 1664 | | <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> |
| 1665 | | <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> |
| 1666 | | </ul> |
| 1667 | | <p id="rfc.section.7.p.2">Each status-code is described below, including any metadata required in the response.</p> |
| 1668 | | <p id="rfc.section.7.p.3">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's |
| 1669 | | media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| 1670 | | </p> |
| 1671 | | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> |
| 1672 | | <p id="rfc.section.7.1.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields, |
| 1673 | | and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did |
| 1674 | | not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. |
| 1675 | | </p> |
| 1676 | | <p id="rfc.section.7.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 |
| 1677 | | (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. |
| 1678 | | </p> |
| 1679 | | <p id="rfc.section.7.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself |
| 1680 | | requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards |
| 1681 | | a request, then it need not forward the corresponding 100 (Continue) response(s).) |
| 1682 | | </p> |
| 1683 | | <div id="rfc.iref.22"></div> |
| 1684 | | <div id="rfc.iref.s.2"></div> |
| 1685 | | <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> |
| 1686 | | <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been |
| 1687 | | received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The |
| 1688 | | server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. |
| 1689 | | </p> |
| 1690 | | <div id="rfc.iref.23"></div> |
| 1691 | | <div id="rfc.iref.s.3"></div> |
| 1692 | | <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> |
| 1693 | | <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined |
| 1694 | | by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
| 1695 | | </p> |
| 1696 | | <p id="rfc.section.7.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over |
| 1697 | | older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use |
| 1698 | | such features. |
| 1699 | | </p> |
| 1700 | | <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> |
| 1701 | | <p id="rfc.section.7.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> |
| 1702 | | <div id="rfc.iref.24"></div> |
| 1703 | | <div id="rfc.iref.s.4"></div> |
| 1704 | | <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> |
| 1705 | | <p id="rfc.section.7.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> |
| 1706 | | <dl> |
| 1707 | | <dt>GET</dt> |
| 1708 | | <dd>a representation of the target resource is sent in the response;</dd> |
| 1709 | | <dt>HEAD</dt> |
| 1710 | | <dd>the same representation as GET, except without the message body;</dd> |
| 1711 | | <dt>POST</dt> |
| 1712 | | <dd>a representation describing or containing the result of the action;</dd> |
| 1713 | | <dt>TRACE</dt> |
| 1714 | | <dd>a representation containing the request message as received by the end server.</dd> |
| 1715 | | </dl> |
| 1716 | | <p id="rfc.section.7.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. |
| 1717 | | </p> |
| 1718 | | <div id="rfc.iref.25"></div> |
| 1719 | | <div id="rfc.iref.s.5"></div> |
| 1720 | | <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> |
| 1721 | | <p id="rfc.section.7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p> |
| 1722 | | <p id="rfc.section.7.2.2.p.2">The newly created resource is typically linked to from the response payload, with the most relevant URI also being carried |
| 1723 | | in the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information |
| 1724 | | can be omitted (e.g., in the case of a response to a PUT request). |
| 1725 | | </p> |
| 1726 | | <p id="rfc.section.7.2.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. |
| 1727 | | </p> |
| 1728 | | <p id="rfc.section.7.2.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource |
| 1729 | | just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
| 1730 | | </p> |
| 1731 | | <div id="rfc.iref.26"></div> |
| 1732 | | <div id="rfc.iref.s.6"></div> |
| 1733 | | <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> |
| 1734 | | <p id="rfc.section.7.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually |
| 1735 | | be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status |
| 1736 | | code from an asynchronous operation such as this. |
| 1737 | | </p> |
| 1738 | | <p id="rfc.section.7.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process |
| 1739 | | (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the |
| 1740 | | server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the |
| 1741 | | user can expect the request to be fulfilled. |
| 1742 | | </p> |
| 1743 | | <div id="rfc.iref.27"></div> |
| 1744 | | <div id="rfc.iref.s.7"></div> |
| 1745 | | <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> |
| 1746 | | <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| 1747 | | </p> |
| 1748 | | <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code |
| 1749 | | before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. |
| 1750 | | </p> |
| 1751 | | <p id="rfc.section.7.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. |
| 1752 | | </p> |
| 1753 | | <div id="rfc.iref.28"></div> |
| 1754 | | <div id="rfc.iref.s.8"></div> |
| 1755 | | <h3 id="rfc.section.7.2.5"><a href="#rfc.section.7.2.5">7.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> |
| 1756 | | <p id="rfc.section.7.2.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional |
| 1757 | | content to return in the response payload body. Metadata in the response header fields refer to the target resource and its |
| 1758 | | current representation after the requested action. |
| 1759 | | </p> |
| 1760 | | <p id="rfc.section.7.2.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, |
| 1761 | | then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource. |
| 1762 | | </p> |
| 1763 | | <p id="rfc.section.7.2.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying |
| 1764 | | that the user agent <em class="bcp14">SHOULD NOT</em> traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication |
| 1765 | | of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the |
| 1766 | | active representation. |
| 1767 | | </p> |
| 1768 | | <p id="rfc.section.7.2.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that |
| 1769 | | the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect |
| 1770 | | automated data transfers to be prevalent, such as within distributed version control systems. |
| 1771 | | </p> |
| 1772 | | <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. |
| 1773 | | </p> |
| 1774 | | <div id="rfc.iref.29"></div> |
| 1775 | | <div id="rfc.iref.s.9"></div> |
| 1776 | | <h3 id="rfc.section.7.2.6"><a href="#rfc.section.7.2.6">7.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> |
| 1777 | | <p id="rfc.section.7.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions |
| 1778 | | to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate |
| 1779 | | another input action. |
| 1780 | | </p> |
| 1781 | | <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. |
| 1782 | | </p> |
| 1783 | | <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> |
| 1784 | | <p id="rfc.section.7.3.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. |
| 1785 | | 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 |
| 1786 | | known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>. |
| 1787 | | </p> |
| 1788 | | <p id="rfc.section.7.3.p.2">There are several types of redirects: </p> |
| 1789 | | <ol> |
| 1790 | | <li> |
| 1791 | | <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header |
| 1792 | | field. In this specification, the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect) fall under |
| 1793 | | this category. |
| 1794 | | </p> |
| 1795 | | </li> |
| 1796 | | <li> |
| 1797 | | <p>Redirection to a new location that represents an indirect response to the request, such as the result of a POST operation |
| 1798 | | to be retrieved with a subsequent GET request. This is status code 303 (See Other). |
| 1799 | | </p> |
| 1800 | | </li> |
| 1801 | | <li> |
| 1802 | | <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices). |
| 1803 | | </p> |
| 1804 | | </li> |
| 1805 | | <li> |
| 1806 | | <p>Other kinds of redirection, such as to a cached result (status code 304 (Not Modified), see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
| 1807 | | </p> |
| 1808 | | </li> |
| 1809 | | </ol> |
| 1810 | | <div class="note" id="rfc.section.7.3.p.3"> |
| 1811 | | <p> <b>Note:</b> In HTTP/1.0, only the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect, and |
| 1812 | | the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to |
| 1813 | | retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code 303 (See Other) |
| 1814 | | (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added |
| 1815 | | yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification |
| 1816 | | makes that behavior conformant in case the original request was POST. |
| 1817 | | </p> |
| | 1708 | to reject the request. |
| | 1709 | </p> |
| | 1710 | <p id="rfc.section.6.9.p.9">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 may be discarded |
| | 1711 | if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. |
| | 1712 | </p> |
| | 1713 | <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the |
| | 1714 | 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 2xx status code unless it has either a direct or tunnel connection established to the authority. |
| | 1715 | </p> |
| | 1716 | <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to |
| | 1717 | the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that |
| | 1718 | peer undelivered, that data will be discarded. |
| | 1719 | </p> |
| | 1720 | <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement |
| | 1721 | CONNECT. |
| | 1722 | </p> |
| | 1723 | </div> |
| 1819 | | <p id="rfc.section.7.3.p.4">A Location 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.5</a>. |
| 1820 | | </p> |
| 1821 | | <p id="rfc.section.7.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was |
| 1822 | | issued. |
| 1823 | | </p> |
| 1824 | | <p id="rfc.section.7.3.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). |
| 1825 | | </p> |
| 1826 | | <div class="note" id="rfc.section.7.3.p.7"> |
| 1827 | | <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. |
| 1828 | | </p> |
| 1829 | | </div> |
| 1830 | | <div id="rfc.iref.30"></div> |
| 1831 | | <div id="rfc.iref.s.10"></div> |
| 1832 | | <h3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> |
| 1833 | | <p id="rfc.section.7.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information |
| 1834 | | (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that |
| 1835 | | location. |
| 1836 | | </p> |
| 1837 | | <p id="rfc.section.7.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can |
| 1838 | | choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection of the most appropriate |
| 1839 | | choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
| 1840 | | </p> |
| 1841 | | <p id="rfc.section.7.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. |
| 1842 | | </p> |
| 1843 | | <p id="rfc.section.7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. |
| 1844 | | </p> |
| 1845 | | <div id="rfc.iref.31"></div> |
| 1846 | | <div id="rfc.iref.s.11"></div> |
| 1847 | | <h3 id="rfc.section.7.3.2"><a href="#rfc.section.7.3.2">7.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> |
| 1848 | | <p id="rfc.section.7.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective |
| 1849 | | request URI to one or more of the new references returned by the server, where possible. |
| 1850 | | </p> |
| 1851 | | <p id="rfc.section.7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. |
| 1852 | | </p> |
| 1853 | | <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| 1854 | | the new URI(s). |
| 1855 | | </p> |
| 1856 | | <div class="note" id="rfc.section.7.3.2.p.4"> |
| 1857 | | <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
| 1858 | | Redirect) can be used instead. |
| 1859 | | </p> |
| 1860 | | </div> |
| 1861 | | <div id="rfc.iref.32"></div> |
| 1862 | | <div id="rfc.iref.s.12"></div> |
| 1863 | | <h3 id="rfc.section.7.3.3"><a href="#rfc.section.7.3.3">7.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> |
| 1864 | | <p id="rfc.section.7.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
| 1865 | | </p> |
| 1866 | | <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| 1867 | | the new URI(s). |
| 1868 | | </p> |
| 1869 | | <div class="note" id="rfc.section.7.3.3.p.3"> |
| 1870 | | <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
| 1871 | | Redirect) can be used instead. |
| 1872 | | </p> |
| 1873 | | </div> |
| 1874 | | <div id="rfc.iref.33"></div> |
| 1875 | | <div id="rfc.iref.s.13"></div> |
| 1876 | | <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> |
| 1877 | | <p id="rfc.section.7.3.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI |
| 1878 | | in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy |
| 1879 | | the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, |
| 1880 | | and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is |
| 1881 | | not considered equivalent to the effective request URI. |
| 1882 | | </p> |
| 1883 | | <p id="rfc.section.7.3.4.p.2">This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to |
| 1884 | | redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response |
| 1885 | | in a form that can be separately identified, bookmarked, and cached independent of the original request. |
| 1886 | | </p> |
| 1887 | | <p id="rfc.section.7.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be |
| 1888 | | transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such |
| 1889 | | that the follow-on representation might be useful to recipients without implying that it adequately represents the target |
| 1890 | | resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might |
| 1891 | | be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). |
| 1892 | | </p> |
| 1893 | | <p id="rfc.section.7.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI. |
| 1894 | | </p> |
| 1895 | | <div id="rfc.iref.34"></div> |
| 1896 | | <div id="rfc.iref.s.14"></div> |
| 1897 | | <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> |
| 1898 | | <p id="rfc.section.7.3.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated. |
| 1899 | | </p> |
| 1900 | | <div id="rfc.iref.35"></div> |
| 1901 | | <div id="rfc.iref.s.15"></div> |
| 1902 | | <h3 id="rfc.section.7.3.6"><a href="#rfc.section.7.3.6">7.3.6</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> |
| 1903 | | <p id="rfc.section.7.3.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> |
| 1904 | | <div id="rfc.iref.36"></div> |
| 1905 | | <div id="rfc.iref.s.16"></div> |
| 1906 | | <h3 id="rfc.section.7.3.7"><a href="#rfc.section.7.3.7">7.3.7</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> |
| 1907 | | <p id="rfc.section.7.3.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
| 1908 | | </p> |
| 1909 | | <p id="rfc.section.7.3.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| 1910 | | the new URI(s). |
| 1911 | | </p> |
| 1912 | | <div class="note" id="rfc.section.7.3.7.p.3"> |
| 1913 | | <p> <b>Note:</b> This status code is similar to 302 Found, except that it does not allow rewriting the request method from POST to GET. This |
| 1914 | | specification defines no equivalent counterpart for 301 Moved Permanently. |
| 1915 | | </p> |
| 1916 | | </div> |
| 1917 | | <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> |
| 1918 | | <p id="rfc.section.7.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD |
| 1919 | | request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
| 1920 | | These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. |
| 1921 | | </p> |
| 1922 | | <div id="rfc.iref.37"></div> |
| 1923 | | <div id="rfc.iref.s.17"></div> |
| 1924 | | <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> |
| 1925 | | <p id="rfc.section.7.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p> |
| 1926 | | <div id="rfc.iref.38"></div> |
| 1927 | | <div id="rfc.iref.s.18"></div> |
| 1928 | | <h3 id="rfc.section.7.4.2"><a href="#rfc.section.7.4.2">7.4.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> |
| 1929 | | <p id="rfc.section.7.4.2.p.1">This code is reserved for future use.</p> |
| 1930 | | <div id="rfc.iref.39"></div> |
| 1931 | | <div id="rfc.iref.s.19"></div> |
| 1932 | | <h3 id="rfc.section.7.4.3"><a href="#rfc.section.7.4.3">7.4.3</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> |
| 1933 | | <p id="rfc.section.7.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might |
| 1934 | | be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials. |
| 1935 | | </p> |
| 1936 | | <p id="rfc.section.7.4.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available |
| 1937 | | to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. |
| 1938 | | </p> |
| 1939 | | <div id="rfc.iref.40"></div> |
| 1940 | | <div id="rfc.iref.s.20"></div> |
| 1941 | | <h3 id="rfc.section.7.4.4"><a href="#rfc.section.7.4.4">7.4.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> |
| 1942 | | <p id="rfc.section.7.4.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary |
| 1943 | | or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable |
| 1944 | | and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request |
| 1945 | | has been refused, or when no other response is applicable. |
| 1946 | | </p> |
| 1947 | | <div id="rfc.iref.41"></div> |
| 1948 | | <div id="rfc.iref.s.21"></div> |
| 1949 | | <h3 id="rfc.section.7.4.5"><a href="#rfc.section.7.4.5">7.4.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> |
| 1950 | | <p id="rfc.section.7.4.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource. |
| 1951 | | </p> |
| 1952 | | <div id="rfc.iref.42"></div> |
| 1953 | | <div id="rfc.iref.s.22"></div> |
| 1954 | | <h3 id="rfc.section.7.4.6"><a href="#rfc.section.7.4.6">7.4.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> |
| 1955 | | <p id="rfc.section.7.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics |
| 1956 | | not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| 1957 | | </p> |
| 1958 | | <p id="rfc.section.7.4.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user |
| 1959 | | or user agent can choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection |
| 1960 | | of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
| 1961 | | </p> |
| 1962 | | <div class="note" id="rfc.section.7.4.6.p.3"> |
| 1963 | | <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the |
| 1964 | | request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the |
| 1965 | | header fields of an incoming response to determine if it is acceptable. |
| 1966 | | </p> |
| 1967 | | </div> |
| 1968 | | <p id="rfc.section.7.4.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. |
| 1969 | | </p> |
| 1970 | | <div id="rfc.iref.43"></div> |
| 1971 | | <div id="rfc.iref.s.23"></div> |
| 1972 | | <h3 id="rfc.section.7.4.7"><a href="#rfc.section.7.4.7">7.4.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> |
| 1973 | | <p id="rfc.section.7.4.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. |
| 1974 | | </p> |
| 1975 | | <div id="rfc.iref.44"></div> |
| 1976 | | <div id="rfc.iref.s.24"></div> |
| 1977 | | <h3 id="rfc.section.7.4.8"><a href="#rfc.section.7.4.8">7.4.8</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> |
| 1978 | | <p id="rfc.section.7.4.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in |
| 1979 | | situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response |
| 1980 | | body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would |
| 1981 | | include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. |
| 1982 | | </p> |
| 1983 | | <p id="rfc.section.7.4.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation |
| 1984 | | being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might |
| 1985 | | use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely |
| 1986 | | contain a list of the differences between the two versions. |
| 1987 | | </p> |
| 1988 | | <div id="rfc.iref.45"></div> |
| 1989 | | <div id="rfc.iref.s.25"></div> |
| 1990 | | <h3 id="rfc.section.7.4.9"><a href="#rfc.section.7.4.9">7.4.9</a> <a id="status.410" href="#status.410">410 Gone</a></h3> |
| 1991 | | <p id="rfc.section.7.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to |
| 1992 | | be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine, |
| 1993 | | whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. |
| 1994 | | </p> |
| 1995 | | <p id="rfc.section.7.4.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource |
| 1996 | | is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event |
| 1997 | | is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's |
| 1998 | | site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time |
| 1999 | | — that is left to the discretion of the server owner. |
| 2000 | | </p> |
| 2001 | | <p id="rfc.section.7.4.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. |
| 2002 | | </p> |
| 2003 | | <div id="rfc.iref.46"></div> |
| 2004 | | <div id="rfc.iref.s.26"></div> |
| 2005 | | <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> |
| 2006 | | <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request |
| 2007 | | message. |
| 2008 | | </p> |
| 2009 | | <div id="rfc.iref.47"></div> |
| 2010 | | <div id="rfc.iref.s.27"></div> |
| 2011 | | <h3 id="rfc.section.7.4.11"><a href="#rfc.section.7.4.11">7.4.11</a> <a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3> |
| 2012 | | <p id="rfc.section.7.4.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able |
| 2013 | | to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. |
| 2014 | | </p> |
| 2015 | | <p id="rfc.section.7.4.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. |
| 2016 | | </p> |
| 2017 | | <div id="rfc.iref.48"></div> |
| 2018 | | <div id="rfc.iref.s.28"></div> |
| 2019 | | <h3 id="rfc.section.7.4.12"><a href="#rfc.section.7.4.12">7.4.12</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> |
| 2020 | | <p id="rfc.section.7.4.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret. |
| 2021 | | This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long |
| 2022 | | query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that |
| 2023 | | points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present |
| 2024 | | in some servers using fixed-length buffers for reading or manipulating the request-target. |
| 2025 | | </p> |
| 2026 | | <div id="rfc.iref.49"></div> |
| 2027 | | <div id="rfc.iref.s.29"></div> |
| 2028 | | <h3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> |
| 2029 | | <p id="rfc.section.7.4.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method |
| 2030 | | on the target resource. |
| 2031 | | </p> |
| 2032 | | <div id="rfc.iref.50"></div> |
| 2033 | | <div id="rfc.iref.s.30"></div> |
| 2034 | | <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> |
| 2035 | | <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could |
| 2036 | | not be met by the next-hop server. |
| 2037 | | </p> |
| 2038 | | <div id="rfc.iref.51"></div> |
| 2039 | | <div id="rfc.iref.s.31"></div> |
| 2040 | | <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> |
| 2041 | | <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. |
| 2042 | | </p> |
| 2043 | | <div id="rfc.figure.u.8"></div> |
| 2044 | | <p>Example:</p> <pre class="text">HTTP/1.1 426 Upgrade Required |
| | 1725 | <div id="status.codes"> |
| | 1726 | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#status.codes">Status Code Definitions</a></h1> |
| | 1727 | <p id="rfc.section.7.p.1">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. |
| | 1728 | There are 5 values for the first digit: |
| | 1729 | </p> |
| | 1730 | <ul> |
| | 1731 | <li>1xx: Informational - Request received, continuing process</li> |
| | 1732 | <li>2xx: Success - The action was successfully received, understood, and accepted</li> |
| | 1733 | <li>3xx: Redirection - Further action must be taken in order to complete the request</li> |
| | 1734 | <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> |
| | 1735 | <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> |
| | 1736 | </ul> |
| | 1737 | <p id="rfc.section.7.p.2">Each status-code is described below, including any metadata required in the response.</p> |
| | 1738 | <p id="rfc.section.7.p.3">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's |
| | 1739 | media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| | 1740 | </p> |
| | 1741 | <div id="status.1xx"> |
| | 1742 | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a href="#status.1xx">Informational 1xx</a></h2> |
| | 1743 | <p id="rfc.section.7.1.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields, |
| | 1744 | and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did |
| | 1745 | not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. |
| | 1746 | </p> |
| | 1747 | <p id="rfc.section.7.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 |
| | 1748 | (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. |
| | 1749 | </p> |
| | 1750 | <p id="rfc.section.7.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself |
| | 1751 | requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards |
| | 1752 | a request, then it need not forward the corresponding 100 (Continue) response(s).) |
| | 1753 | </p> |
| | 1754 | <div id="status.100"> |
| | 1755 | <div id="rfc.iref.1.1"></div> |
| | 1756 | <div id="rfc.iref.s.2"></div> |
| | 1757 | <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a href="#status.100">100 Continue</a></h3> |
| | 1758 | <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been |
| | 1759 | received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The |
| | 1760 | server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. |
| | 1761 | </p> |
| | 1762 | </div> |
| | 1763 | <div id="status.101"> |
| | 1764 | <div id="rfc.iref.1.2"></div> |
| | 1765 | <div id="rfc.iref.s.3"></div> |
| | 1766 | <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a href="#status.101">101 Switching Protocols</a></h3> |
| | 1767 | <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined |
| | 1768 | by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
| | 1769 | </p> |
| | 1770 | <p id="rfc.section.7.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over |
| | 1771 | older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use |
| | 1772 | such features. |
| | 1773 | </p> |
| | 1774 | </div> |
| | 1775 | </div> |
| | 1776 | <div id="status.2xx"> |
| | 1777 | <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a href="#status.2xx">Successful 2xx</a></h2> |
| | 1778 | <p id="rfc.section.7.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> |
| | 1779 | <div id="status.200"> |
| | 1780 | <div id="rfc.iref.2.1"></div> |
| | 1781 | <div id="rfc.iref.s.4"></div> |
| | 1782 | <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a href="#status.200">200 OK</a></h3> |
| | 1783 | <p id="rfc.section.7.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> |
| | 1784 | <dl> |
| | 1785 | <dt>GET</dt> |
| | 1786 | <dd>a representation of the target resource is sent in the response;</dd> |
| | 1787 | <dt>HEAD</dt> |
| | 1788 | <dd>the same representation as GET, except without the message body;</dd> |
| | 1789 | <dt>POST</dt> |
| | 1790 | <dd>a representation describing or containing the result of the action;</dd> |
| | 1791 | <dt>TRACE</dt> |
| | 1792 | <dd>a representation containing the request message as received by the end server.</dd> |
| | 1793 | </dl> |
| | 1794 | <p id="rfc.section.7.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. |
| | 1795 | </p> |
| | 1796 | </div> |
| | 1797 | <div id="status.201"> |
| | 1798 | <div id="rfc.iref.2.2"></div> |
| | 1799 | <div id="rfc.iref.s.5"></div> |
| | 1800 | <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a href="#status.201">201 Created</a></h3> |
| | 1801 | <p id="rfc.section.7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p> |
| | 1802 | <p id="rfc.section.7.2.2.p.2">The newly created resource is typically linked to from the response payload, with the most relevant URI also being carried |
| | 1803 | in the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information |
| | 1804 | can be omitted (e.g., in the case of a response to a PUT request). |
| | 1805 | </p> |
| | 1806 | <p id="rfc.section.7.2.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. |
| | 1807 | </p> |
| | 1808 | <p id="rfc.section.7.2.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource |
| | 1809 | just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
| | 1810 | </p> |
| | 1811 | </div> |
| | 1812 | <div id="status.202"> |
| | 1813 | <div id="rfc.iref.2.3"></div> |
| | 1814 | <div id="rfc.iref.s.6"></div> |
| | 1815 | <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a href="#status.202">202 Accepted</a></h3> |
| | 1816 | <p id="rfc.section.7.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually |
| | 1817 | be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status |
| | 1818 | code from an asynchronous operation such as this. |
| | 1819 | </p> |
| | 1820 | <p id="rfc.section.7.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process |
| | 1821 | (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the |
| | 1822 | server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the |
| | 1823 | user can expect the request to be fulfilled. |
| | 1824 | </p> |
| | 1825 | </div> |
| | 1826 | <div id="status.203"> |
| | 1827 | <div id="rfc.iref.2.4"></div> |
| | 1828 | <div id="rfc.iref.s.7"></div> |
| | 1829 | <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a href="#status.203">203 Non-Authoritative Information</a></h3> |
| | 1830 | <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
| | 1831 | </p> |
| | 1832 | <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code |
| | 1833 | before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. |
| | 1834 | </p> |
| | 1835 | <p id="rfc.section.7.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. |
| | 1836 | </p> |
| | 1837 | </div> |
| | 1838 | <div id="status.204"> |
| | 1839 | <div id="rfc.iref.2.5"></div> |
| | 1840 | <div id="rfc.iref.s.8"></div> |
| | 1841 | <h3 id="rfc.section.7.2.5"><a href="#rfc.section.7.2.5">7.2.5</a> <a href="#status.204">204 No Content</a></h3> |
| | 1842 | <p id="rfc.section.7.2.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional |
| | 1843 | content to return in the response payload body. Metadata in the response header fields refer to the target resource and its |
| | 1844 | current representation after the requested action. |
| | 1845 | </p> |
| | 1846 | <p id="rfc.section.7.2.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, |
| | 1847 | then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource. |
| | 1848 | </p> |
| | 1849 | <p id="rfc.section.7.2.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying |
| | 1850 | that the user agent <em class="bcp14">SHOULD NOT</em> traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication |
| | 1851 | of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the |
| | 1852 | active representation. |
| | 1853 | </p> |
| | 1854 | <p id="rfc.section.7.2.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that |
| | 1855 | the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect |
| | 1856 | automated data transfers to be prevalent, such as within distributed version control systems. |
| | 1857 | </p> |
| | 1858 | <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. |
| | 1859 | </p> |
| | 1860 | </div> |
| | 1861 | <div id="status.205"> |
| | 1862 | <div id="rfc.iref.2.6"></div> |
| | 1863 | <div id="rfc.iref.s.9"></div> |
| | 1864 | <h3 id="rfc.section.7.2.6"><a href="#rfc.section.7.2.6">7.2.6</a> <a href="#status.205">205 Reset Content</a></h3> |
| | 1865 | <p id="rfc.section.7.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions |
| | 1866 | to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate |
| | 1867 | another input action. |
| | 1868 | </p> |
| | 1869 | <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. |
| | 1870 | </p> |
| | 1871 | </div> |
| | 1872 | </div> |
| | 1873 | <div id="status.3xx"> |
| | 1874 | <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a href="#status.3xx">Redirection 3xx</a></h2> |
| | 1875 | <p id="rfc.section.7.3.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. |
| | 1876 | 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 |
| | 1877 | known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>. |
| | 1878 | </p> |
| | 1879 | <p id="rfc.section.7.3.p.2">There are several types of redirects: </p> |
| | 1880 | <ol> |
| | 1881 | <li> |
| | 1882 | <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header |
| | 1883 | field. In this specification, the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect) fall under |
| | 1884 | this category. |
| | 1885 | </p> |
| | 1886 | </li> |
| | 1887 | <li> |
| | 1888 | <p>Redirection to a new location that represents an indirect response to the request, such as the result of a POST operation |
| | 1889 | to be retrieved with a subsequent GET request. This is status code 303 (See Other). |
| | 1890 | </p> |
| | 1891 | </li> |
| | 1892 | <li> |
| | 1893 | <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices). |
| | 1894 | </p> |
| | 1895 | </li> |
| | 1896 | <li> |
| | 1897 | <p>Other kinds of redirection, such as to a cached result (status code 304 (Not Modified), see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
| | 1898 | </p> |
| | 1899 | </li> |
| | 1900 | </ol> |
| | 1901 | <div class="note" id="rfc.section.7.3.p.3"> |
| | 1902 | <p><b>Note:</b> In HTTP/1.0, only the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect, and |
| | 1903 | the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="https://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to |
| | 1904 | retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code 303 (See Other) |
| | 1905 | (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added |
| | 1906 | yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification |
| | 1907 | makes that behavior conformant in case the original request was POST. |
| | 1908 | </p> |
| | 1909 | </div> |
| | 1910 | <p id="rfc.section.7.3.p.4">A Location 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.5</a>. |
| | 1911 | </p> |
| | 1912 | <p id="rfc.section.7.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was |
| | 1913 | issued. |
| | 1914 | </p> |
| | 1915 | <p id="rfc.section.7.3.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). |
| | 1916 | </p> |
| | 1917 | <div class="note" id="rfc.section.7.3.p.7"> |
| | 1918 | <p><b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. |
| | 1919 | </p> |
| | 1920 | </div> |
| | 1921 | <div id="status.300"> |
| | 1922 | <div id="rfc.iref.3.1"></div> |
| | 1923 | <div id="rfc.iref.s.10"></div> |
| | 1924 | <h3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a href="#status.300">300 Multiple Choices</a></h3> |
| | 1925 | <p id="rfc.section.7.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information |
| | 1926 | (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that |
| | 1927 | location. |
| | 1928 | </p> |
| | 1929 | <p id="rfc.section.7.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can |
| | 1930 | choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection of the most appropriate |
| | 1931 | choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
| | 1932 | </p> |
| | 1933 | <p id="rfc.section.7.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. |
| | 1934 | </p> |
| | 1935 | <p id="rfc.section.7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. |
| | 1936 | </p> |
| | 1937 | </div> |
| | 1938 | <div id="status.301"> |
| | 1939 | <div id="rfc.iref.3.2"></div> |
| | 1940 | <div id="rfc.iref.s.11"></div> |
| | 1941 | <h3 id="rfc.section.7.3.2"><a href="#rfc.section.7.3.2">7.3.2</a> <a href="#status.301">301 Moved Permanently</a></h3> |
| | 1942 | <p id="rfc.section.7.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective |
| | 1943 | request URI to one or more of the new references returned by the server, where possible. |
| | 1944 | </p> |
| | 1945 | <p id="rfc.section.7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. |
| | 1946 | </p> |
| | 1947 | <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| | 1948 | the new URI(s). |
| | 1949 | </p> |
| | 1950 | <div class="note" id="rfc.section.7.3.2.p.4"> |
| | 1951 | <p><b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
| | 1952 | Redirect) can be used instead. |
| | 1953 | </p> |
| | 1954 | </div> |
| | 1955 | </div> |
| | 1956 | <div id="status.302"> |
| | 1957 | <div id="rfc.iref.3.3"></div> |
| | 1958 | <div id="rfc.iref.s.12"></div> |
| | 1959 | <h3 id="rfc.section.7.3.3"><a href="#rfc.section.7.3.3">7.3.3</a> <a href="#status.302">302 Found</a></h3> |
| | 1960 | <p id="rfc.section.7.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
| | 1961 | </p> |
| | 1962 | <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| | 1963 | the new URI(s). |
| | 1964 | </p> |
| | 1965 | <div class="note" id="rfc.section.7.3.3.p.3"> |
| | 1966 | <p><b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
| | 1967 | Redirect) can be used instead. |
| | 1968 | </p> |
| | 1969 | </div> |
| | 1970 | </div> |
| | 1971 | <div id="status.303"> |
| | 1972 | <div id="rfc.iref.3.4"></div> |
| | 1973 | <div id="rfc.iref.s.13"></div> |
| | 1974 | <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <a href="#status.303">303 See Other</a></h3> |
| | 1975 | <p id="rfc.section.7.3.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI |
| | 1976 | in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy |
| | 1977 | the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, |
| | 1978 | and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is |
| | 1979 | not considered equivalent to the effective request URI. |
| | 1980 | </p> |
| | 1981 | <p id="rfc.section.7.3.4.p.2">This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to |
| | 1982 | redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response |
| | 1983 | in a form that can be separately identified, bookmarked, and cached independent of the original request. |
| | 1984 | </p> |
| | 1985 | <p id="rfc.section.7.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be |
| | 1986 | transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such |
| | 1987 | that the follow-on representation might be useful to recipients without implying that it adequately represents the target |
| | 1988 | resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might |
| | 1989 | be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). |
| | 1990 | </p> |
| | 1991 | <p id="rfc.section.7.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI. |
| | 1992 | </p> |
| | 1993 | </div> |
| | 1994 | <div id="status.305"> |
| | 1995 | <div id="rfc.iref.3.5"></div> |
| | 1996 | <div id="rfc.iref.s.14"></div> |
| | 1997 | <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a> <a href="#status.305">305 Use Proxy</a></h3> |
| | 1998 | <p id="rfc.section.7.3.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated. |
| | 1999 | </p> |
| | 2000 | </div> |
| | 2001 | <div id="status.306"> |
| | 2002 | <div id="rfc.iref.3.6"></div> |
| | 2003 | <div id="rfc.iref.s.15"></div> |
| | 2004 | <h3 id="rfc.section.7.3.6"><a href="#rfc.section.7.3.6">7.3.6</a> <a href="#status.306">306 (Unused)</a></h3> |
| | 2005 | <p id="rfc.section.7.3.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> |
| | 2006 | </div> |
| | 2007 | <div id="status.307"> |
| | 2008 | <div id="rfc.iref.3.7"></div> |
| | 2009 | <div id="rfc.iref.s.16"></div> |
| | 2010 | <h3 id="rfc.section.7.3.7"><a href="#rfc.section.7.3.7">7.3.7</a> <a href="#status.307">307 Temporary Redirect</a></h3> |
| | 2011 | <p id="rfc.section.7.3.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
| | 2012 | </p> |
| | 2013 | <p id="rfc.section.7.3.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
| | 2014 | the new URI(s). |
| | 2015 | </p> |
| | 2016 | <div class="note" id="rfc.section.7.3.7.p.3"> |
| | 2017 | <p><b>Note:</b> This status code is similar to 302 Found, except that it does not allow rewriting the request method from POST to GET. This |
| | 2018 | specification defines no equivalent counterpart for 301 Moved Permanently. |
| | 2019 | </p> |
| | 2020 | </div> |
| | 2021 | </div> |
| | 2022 | </div> |
| | 2023 | <div id="status.4xx"> |
| | 2024 | <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a href="#status.4xx">Client Error 4xx</a></h2> |
| | 2025 | <p id="rfc.section.7.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD |
| | 2026 | request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
| | 2027 | These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. |
| | 2028 | </p> |
| | 2029 | <div id="status.400"> |
| | 2030 | <div id="rfc.iref.4.1"></div> |
| | 2031 | <div id="rfc.iref.s.17"></div> |
| | 2032 | <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a href="#status.400">400 Bad Request</a></h3> |
| | 2033 | <p id="rfc.section.7.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p> |
| | 2034 | </div> |
| | 2035 | <div id="status.402"> |
| | 2036 | <div id="rfc.iref.4.2"></div> |
| | 2037 | <div id="rfc.iref.s.18"></div> |
| | 2038 | <h3 id="rfc.section.7.4.2"><a href="#rfc.section.7.4.2">7.4.2</a> <a href="#status.402">402 Payment Required</a></h3> |
| | 2039 | <p id="rfc.section.7.4.2.p.1">This code is reserved for future use.</p> |
| | 2040 | </div> |
| | 2041 | <div id="status.403"> |
| | 2042 | <div id="rfc.iref.4.3"></div> |
| | 2043 | <div id="rfc.iref.s.19"></div> |
| | 2044 | <h3 id="rfc.section.7.4.3"><a href="#rfc.section.7.4.3">7.4.3</a> <a href="#status.403">403 Forbidden</a></h3> |
| | 2045 | <p id="rfc.section.7.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might |
| | 2046 | be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials. |
| | 2047 | </p> |
| | 2048 | <p id="rfc.section.7.4.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available |
| | 2049 | to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. |
| | 2050 | </p> |
| | 2051 | </div> |
| | 2052 | <div id="status.404"> |
| | 2053 | <div id="rfc.iref.4.4"></div> |
| | 2054 | <div id="rfc.iref.s.20"></div> |
| | 2055 | <h3 id="rfc.section.7.4.4"><a href="#rfc.section.7.4.4">7.4.4</a> <a href="#status.404">404 Not Found</a></h3> |
| | 2056 | <p id="rfc.section.7.4.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary |
| | 2057 | or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable |
| | 2058 | and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request |
| | 2059 | has been refused, or when no other response is applicable. |
| | 2060 | </p> |
| | 2061 | </div> |
| | 2062 | <div id="status.405"> |
| | 2063 | <div id="rfc.iref.4.5"></div> |
| | 2064 | <div id="rfc.iref.s.21"></div> |
| | 2065 | <h3 id="rfc.section.7.4.5"><a href="#rfc.section.7.4.5">7.4.5</a> <a href="#status.405">405 Method Not Allowed</a></h3> |
| | 2066 | <p id="rfc.section.7.4.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource. |
| | 2067 | </p> |
| | 2068 | </div> |
| | 2069 | <div id="status.406"> |
| | 2070 | <div id="rfc.iref.4.6"></div> |
| | 2071 | <div id="rfc.iref.s.22"></div> |
| | 2072 | <h3 id="rfc.section.7.4.6"><a href="#rfc.section.7.4.6">7.4.6</a> <a href="#status.406">406 Not Acceptable</a></h3> |
| | 2073 | <p id="rfc.section.7.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics |
| | 2074 | not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
| | 2075 | </p> |
| | 2076 | <p id="rfc.section.7.4.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user |
| | 2077 | or user agent can choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection |
| | 2078 | of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
| | 2079 | </p> |
| | 2080 | <div class="note" id="rfc.section.7.4.6.p.3"> |
| | 2081 | <p><b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the |
| | 2082 | request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the |
| | 2083 | header fields of an incoming response to determine if it is acceptable. |
| | 2084 | </p> |
| | 2085 | </div> |
| | 2086 | <p id="rfc.section.7.4.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. |
| | 2087 | </p> |
| | 2088 | </div> |
| | 2089 | <div id="status.408"> |
| | 2090 | <div id="rfc.iref.4.7"></div> |
| | 2091 | <div id="rfc.iref.s.23"></div> |
| | 2092 | <h3 id="rfc.section.7.4.7"><a href="#rfc.section.7.4.7">7.4.7</a> <a href="#status.408">408 Request Timeout</a></h3> |
| | 2093 | <p id="rfc.section.7.4.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. |
| | 2094 | </p> |
| | 2095 | </div> |
| | 2096 | <div id="status.409"> |
| | 2097 | <div id="rfc.iref.4.8"></div> |
| | 2098 | <div id="rfc.iref.s.24"></div> |
| | 2099 | <h3 id="rfc.section.7.4.8"><a href="#rfc.section.7.4.8">7.4.8</a> <a href="#status.409">409 Conflict</a></h3> |
| | 2100 | <p id="rfc.section.7.4.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in |
| | 2101 | situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response |
| | 2102 | body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would |
| | 2103 | include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. |
| | 2104 | </p> |
| | 2105 | <p id="rfc.section.7.4.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation |
| | 2106 | being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might |
| | 2107 | use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely |
| | 2108 | contain a list of the differences between the two versions. |
| | 2109 | </p> |
| | 2110 | </div> |
| | 2111 | <div id="status.410"> |
| | 2112 | <div id="rfc.iref.4.9"></div> |
| | 2113 | <div id="rfc.iref.s.25"></div> |
| | 2114 | <h3 id="rfc.section.7.4.9"><a href="#rfc.section.7.4.9">7.4.9</a> <a href="#status.410">410 Gone</a></h3> |
| | 2115 | <p id="rfc.section.7.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to |
| | 2116 | be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine, |
| | 2117 | whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. |
| | 2118 | </p> |
| | 2119 | <p id="rfc.section.7.4.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource |
| | 2120 | is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event |
| | 2121 | is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's |
| | 2122 | site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time |
| | 2123 | — that is left to the discretion of the server owner. |
| | 2124 | </p> |
| | 2125 | <p id="rfc.section.7.4.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. |
| | 2126 | </p> |
| | 2127 | </div> |
| | 2128 | <div id="status.411"> |
| | 2129 | <div id="rfc.iref.4.10"></div> |
| | 2130 | <div id="rfc.iref.s.26"></div> |
| | 2131 | <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a href="#status.411">411 Length Required</a></h3> |
| | 2132 | <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request |
| | 2133 | message. |
| | 2134 | </p> |
| | 2135 | </div> |
| | 2136 | <div id="status.413"> |
| | 2137 | <div id="rfc.iref.4.11"></div> |
| | 2138 | <div id="rfc.iref.s.27"></div> |
| | 2139 | <h3 id="rfc.section.7.4.11"><a href="#rfc.section.7.4.11">7.4.11</a> <a href="#status.413">413 Request Representation Too Large</a></h3> |
| | 2140 | <p id="rfc.section.7.4.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able |
| | 2141 | to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. |
| | 2142 | </p> |
| | 2143 | <p id="rfc.section.7.4.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. |
| | 2144 | </p> |
| | 2145 | </div> |
| | 2146 | <div id="status.414"> |
| | 2147 | <div id="rfc.iref.4.12"></div> |
| | 2148 | <div id="rfc.iref.s.28"></div> |
| | 2149 | <h3 id="rfc.section.7.4.12"><a href="#rfc.section.7.4.12">7.4.12</a> <a href="#status.414">414 URI Too Long</a></h3> |
| | 2150 | <p id="rfc.section.7.4.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret. |
| | 2151 | This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long |
| | 2152 | query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that |
| | 2153 | points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present |
| | 2154 | in some servers using fixed-length buffers for reading or manipulating the request-target. |
| | 2155 | </p> |
| | 2156 | </div> |
| | 2157 | <div id="status.415"> |
| | 2158 | <div id="rfc.iref.4.13"></div> |
| | 2159 | <div id="rfc.iref.s.29"></div> |
| | 2160 | <h3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a> <a href="#status.415">415 Unsupported Media Type</a></h3> |
| | 2161 | <p id="rfc.section.7.4.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method |
| | 2162 | on the target resource. |
| | 2163 | </p> |
| | 2164 | </div> |
| | 2165 | <div id="status.417"> |
| | 2166 | <div id="rfc.iref.4.14"></div> |
| | 2167 | <div id="rfc.iref.s.30"></div> |
| | 2168 | <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a> <a href="#status.417">417 Expectation Failed</a></h3> |
| | 2169 | <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could |
| | 2170 | not be met by the next-hop server. |
| | 2171 | </p> |
| | 2172 | </div> |
| | 2173 | <div id="status.426"> |
| | 2174 | <div id="rfc.iref.4.15"></div> |
| | 2175 | <div id="rfc.iref.s.31"></div> |
| | 2176 | <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a href="#status.426">426 Upgrade Required</a></h3> |
| | 2177 | <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. |
| | 2178 | </p> |
| | 2179 | <div id="rfc.figure.u.8"></div> |
| | 2180 | <p>Example:</p><pre class="text">HTTP/1.1 426 Upgrade Required |
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)