Changeset 1713 for draft-ietf-httpbis
- Timestamp:
- 04/07/12 17:59:15 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1710 r1713 1171 1171 </p> 1172 1172 <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters 1173 directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. 1174 Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately 1173 directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a 301 (Moved Permanently) redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately 1175 1174 crafted to bypass security filters along the request chain. 1176 1175 </p> 1177 1176 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1178 it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1179 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1177 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1180 1178 </p> 1181 1179 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. … … 1466 1464 the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header 1467 1465 field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot 1468 be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request)status code and then close the connection.1466 be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. 1469 1467 </p> 1470 1468 <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding … … 1476 1474 <li> 1477 1475 <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing 1478 field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, 1479 the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent, 1476 field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent, 1480 1477 it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. 1481 1478 </p> … … 1501 1498 with HTTP/1.0. 1502 1499 </p> 1503 <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).1500 <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. 1504 1501 </p> 1505 1502 <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding, 1506 since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the1507 chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in1508 advance of being called and the server is unable or unwilling to buffer the entirerequest before processing.1503 since some existing services respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via 1504 a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire 1505 request before processing. 1509 1506 </p> 1510 1507 <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such … … 1542 1539 <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request 1543 1540 message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed 1544 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request)response.1541 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. 1545 1542 </p> 1546 1543 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> … … 1856 1853 without first verifying that the intercepted connection is targeting a valid IP address for that host. 1857 1854 </p> 1858 <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request1859 message that contains more thanone Host header field or a Host header field with an invalid field-value.1855 <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than 1856 one Host header field or a Host header field with an invalid field-value. 1860 1857 </p> 1861 1858 <div id="rfc.iref.e.1"></div> … … 2182 2179 </ul> 2183 2180 <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 2184 100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client 2185 sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code, 2186 the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. 2181 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a 100 (Continue) status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) 2182 from which it has never seen a 100 (Continue) status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. 2187 2183 </p> 2188 2184 <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p> … … 2216 2212 it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 2217 2213 </li> 2218 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed)status code.2214 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code. 2219 2215 </li> 2220 2216 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. … … 2262 2258 </p> 2263 2259 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched 2264 to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required)responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.2260 to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2265 2261 </p> 2266 2262 <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined -
draft-ietf-httpbis/latest/p1-messaging.xml
r1710 r1713 1060 1060 directly instead of properly percent-encoding the disallowed characters. 1061 1061 Recipients of an invalid request-line &SHOULD; respond with either a 1062 400 (Bad Request)error or a 301 (Moved Permanently) redirect with the1062 <x:ref>400 (Bad Request)</x:ref> error or a 301 (Moved Permanently) redirect with the 1063 1063 request-target properly encoded. Recipients &SHOULD-NOT; attempt to 1064 1064 autocorrect and then process the request without a redirect, since the … … 1069 1069 HTTP does not place a pre-defined limit on the length of a request-line. 1070 1070 A server that receives a method longer than any that it implements 1071 &SHOULD; respond with either a 405 (Not Allowed), if it is an origin1071 &SHOULD; respond with either a <x:ref>405 (Method Not Allowed)</x:ref>, if it is an origin 1072 1072 server, or a <x:ref>501 (Not Implemented)</x:ref> status code. 1073 1073 A server &MUST; be prepared to receive URIs of unbounded length and 1074 respond with the 414 (URI Too Long)status code if the received1074 respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received 1075 1075 request-target would be longer than the server wishes to handle 1076 1076 (see &status-414;). … … 1669 1669 "chunked" transfer-coding is not the final encoding, the message body 1670 1670 length cannot be determined reliably; the server &MUST; respond with 1671 the 400 (Bad Request)status code and then close the connection.1671 the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. 1672 1672 </t> 1673 1673 <t> … … 1688 1688 prevent request or response smuggling. 1689 1689 If this is a request message, the server &MUST; respond with 1690 a 400 (Bad Request)status code and then close the connection.1690 a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. 1691 1691 If this is a response message received by a proxy, the proxy 1692 1692 &MUST; discard the received response, send a <x:ref>502 (Bad Gateway)</x:ref> … … 1730 1730 <t> 1731 1731 A server &MAY; reject a request that contains a message body but 1732 not a Content-Length by responding with 411 (Length Required).1732 not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>. 1733 1733 </t> 1734 1734 <t> … … 1737 1737 use a valid Content-Length header field if the message body length 1738 1738 is known in advance, rather than the "chunked" encoding, since some 1739 existing services respond to "chunked" with a 411 (Length Required)1739 existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref> 1740 1740 status code even though they understand the chunked encoding. This 1741 1741 is typically because such services are implemented via a gateway that … … 1821 1821 receives a sequence of octets that does not match the HTTP-message 1822 1822 grammar aside from the robustness exceptions listed above, the 1823 server &MUST; respond with an HTTP/1.1 400 (Bad Request)response.1823 server &MUST; respond with an HTTP/1.1 <x:ref>400 (Bad Request)</x:ref> response. 1824 1824 </t> 1825 1825 </section> … … 2410 2410 </t> 2411 2411 <t> 2412 A server &MUST; respond with a 400 (Bad Request) status code to2413 any HTTP/1.1 request message that lacks a Host header field and2412 A server &MUST; respond with a <x:ref>400 (Bad Request)</x:ref> status code 2413 to any HTTP/1.1 request message that lacks a Host header field and 2414 2414 to any request message that contains more than one Host header field 2415 2415 or a Host header field with an invalid field-value. … … 3117 3117 Because of the presence of older implementations, the protocol allows 3118 3118 ambiguous situations in which a client might send "Expect: 100-continue" 3119 without receiving either a 417 (Expectation Failed)3119 without receiving either a <x:ref>417 (Expectation Failed)</x:ref> 3120 3120 or a 100 (Continue) status code. Therefore, when a client sends this 3121 3121 header field to an origin server (possibly via a proxy) from which it … … 3185 3185 <t> If the proxy knows that the version of the next-hop server is 3186 3186 HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST; 3187 respond with a 417 (Expectation Failed)status code.3187 respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. 3188 3188 </t> 3189 3189 <t> Proxies &SHOULD; maintain a record of the HTTP version … … 3277 3277 Servers &MUST; include the "Upgrade" header field in 101 (Switching 3278 3278 Protocols) responses to indicate which protocol(s) are being switched to, 3279 and &MUST; include it in 426 (Upgrade Required)responses to indicate3279 and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate 3280 3280 acceptable protocols to upgrade to. Servers &MAY; include it in any other 3281 3281 response to indicate that they are willing to upgrade to one of the … … 4109 4109 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> 4110 4110 <x:source href="p2-semantics.xml" basename="p2-semantics"> 4111 <x:defines>400 (Bad Request)</x:defines> 4112 <x:defines>405 (Method Not Allowed)</x:defines> 4113 <x:defines>411 (Length Required)</x:defines> 4114 <x:defines>414 (URI Too Long)</x:defines> 4115 <x:defines>417 (Expectation Failed)</x:defines> 4116 <x:defines>426 (Upgrade Required)</x:defines> 4111 4117 <x:defines>501 (Not Implemented)</x:defines> 4112 4118 <x:defines>502 (Bad Gateway)</x:defines> -
draft-ietf-httpbis/latest/p2-semantics.html
r1712 r1713 891 891 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> 892 892 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 893 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the 894 resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 2.3</a>. 893 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 2.3</a>. 895 894 </p> 896 895 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> … … 1054 1053 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 1055 1054 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 1056 appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) 1057 or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type 1058 values. 1055 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values. 1059 1056 </p> 1060 1057 <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being … … 1920 1917 </p> 1921 1918 <p id="rfc.section.4.6.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 1922 to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. 1919 to the client, the status code <a href="#status.404" class="smpl">404 1920 (Not Found)</a> <em class="bcp14">MAY</em> be used instead. 1923 1921 </p> 1924 1922 <div id="rfc.iref.39"></div> … … 1926 1924 <h3 id="rfc.section.4.6.4"><a href="#rfc.section.4.6.4">4.6.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1927 1925 <p id="rfc.section.4.6.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary 1928 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 unavailable1926 or permanent. The <a href="#status.410" class="smpl">410 (Gone)</a> status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1929 1927 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request 1930 1928 has been refused, or when no other response is applicable. … … 1976 1974 <p id="rfc.section.4.6.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to 1977 1975 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, 1978 whether or not the condition is permanent, the status code 404 (Not Found)<em class="bcp14">SHOULD</em> be used instead.1976 whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a> <em class="bcp14">SHOULD</em> be used instead. 1979 1977 </p> 1980 1978 <p id="rfc.section.4.6.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource … … 2536 2534 <p id="rfc.section.8.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor 2537 2535 them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response 2538 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 2536 that doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406 2537 (Not Acceptable)</a> response. 2539 2538 </p> 2540 2539 <p id="rfc.section.8.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. … … 2566 2565 and used within HTTP/1.1. 2567 2566 </p> 2568 <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation2569 when the server is unwilling or unable to provide a varying response usingserver-driven negotiation.2567 <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using 2568 server-driven negotiation. 2570 2569 </p> 2571 2570 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> … … 2609 2608 <p id="rfc.section.9.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept 2610 2609 header field is present in a request and none of the available representations for the response have a media type that is 2611 listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating 2612 the response as if it is not subject to content negotiation. 2610 listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept header field by treating the response as if it is not subject to content negotiation. 2613 2611 </p> 2614 2612 <p id="rfc.section.9.1.p.10">A more elaborate example is</p> … … 2693 2691 <p id="rfc.section.9.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response. 2694 2692 If an Accept-Charset header field is present in a request and none of the available representations for the response have 2695 a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header 2696 field by treating the response as if it is not subject to content negotiation. 2693 a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept-Charset header field by treating the response as if it is not subject to content negotiation. 2697 2694 </p> 2698 2695 <div id="rfc.iref.a.3"></div> … … 2938 2935 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2939 2936 </pre><p id="rfc.section.9.11.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2940 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed)status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.2937 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2941 2938 </p> 2942 2939 <p id="rfc.section.9.11.p.4">The only expectation defined by this specification is:</p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1712 r1713 391 391 always notifies the client whether a method is currently allowed on a 392 392 resource, since the set of allowed methods can change dynamically. An 393 origin server &SHOULD; respond with the status code 405 (Method Not Allowed)393 origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref> 394 394 if the method is known by the origin server but not allowed for the 395 395 resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is … … 731 731 representation or changing the resource configuration, or respond 732 732 with an appropriate error message containing sufficient information 733 to explain why the representation is unsuitable. The 409 (Conflict)734 or 415 (Unsupported Media Type)status codes are suggested, with the733 to explain why the representation is unsuitable. The <x:ref>409 (Conflict)</x:ref> 734 or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the 735 735 latter being specific to constraints on Content-Type values. 736 736 </t> … … 1764 1764 <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/> 1765 1765 <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/> 1766 <x:anchor-alias value="400 (Bad Request)"/> 1766 1767 <t> 1767 1768 The server cannot or will not process the request, due to a client error (e.g., … … 1781 1782 <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/> 1782 1783 <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/> 1784 <x:anchor-alias value="403 (Forbidden)"/> 1783 1785 <t> 1784 1786 The server understood the request, but refuses to authorize it. Providing … … 1791 1793 public why the request has not been fulfilled, it &SHOULD; describe the 1792 1794 reason for the refusal in the representation. If the server does not wish to 1793 make this information available to the client, the status code 4041794 (Not Found) &MAY; be used instead.1795 make this information available to the client, the status code <x:ref>404 1796 (Not Found)</x:ref> &MAY; be used instead. 1795 1797 </t> 1796 1798 </section> … … 1799 1801 <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/> 1800 1802 <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 1803 <x:anchor-alias value="404 (Not Found)"/> 1801 1804 <t> 1802 1805 The server has not found anything matching the effective request URI. No 1803 1806 indication is given of whether the condition is temporary or 1804 permanent. The 410 (Gone)status code &SHOULD; be used if the server1807 permanent. The <x:ref>410 (Gone)</x:ref> status code &SHOULD; be used if the server 1805 1808 knows, through some internally configurable mechanism, that an old 1806 1809 resource is permanently unavailable and has no forwarding address. … … 1814 1817 <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/> 1815 1818 <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> 1819 <x:anchor-alias value="405 (Method Not Allowed)"/> 1816 1820 <t> 1817 1821 The method specified in the request-line is not allowed for the target … … 1824 1828 <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/> 1825 1829 <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/> 1830 <x:anchor-alias value="406 (Not Acceptable)"/> 1826 1831 <t> 1827 1832 The resource identified by the request is only capable of generating … … 1867 1872 <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/> 1868 1873 <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/> 1874 <x:anchor-alias value="409 (Conflict)"/> 1869 1875 <t> 1870 1876 The request could not be completed due to a conflict with the current … … 1891 1897 <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/> 1892 1898 <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/> 1899 <x:anchor-alias value="410 (Gone)"/> 1893 1900 <t> 1894 1901 The target resource is no longer available at the server and no … … 1897 1904 delete references to the effective request URI after user approval. If the 1898 1905 server does not know, or has no facility to determine, whether or not 1899 the condition is permanent, the status code 404 (Not Found) &SHOULD; be1900 used instead.1906 the condition is permanent, the status code <x:ref>404 (Not Found)</x:ref> 1907 &SHOULD; be used instead. 1901 1908 </t> 1902 1909 <t> … … 1920 1927 <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/> 1921 1928 <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/> 1929 <x:anchor-alias value="411 (Length Required)"/> 1922 1930 <t> 1923 1931 The server refuses to accept the request without a defined Content-Length. … … 1947 1955 <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/> 1948 1956 <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 1957 <x:anchor-alias value="414 (URI Too Long)"/> 1949 1958 <t> 1950 1959 The server is refusing to service the request because the effective request URI … … 1963 1972 <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/> 1964 1973 <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/> 1974 <x:anchor-alias value="415 (Unsupported Media Type)"/> 1965 1975 <t> 1966 1976 The server is refusing to service the request because the request … … 1973 1983 <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/> 1974 1984 <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/> 1985 <x:anchor-alias value="417 (Expectation Failed)"/> 1975 1986 <t> 1976 1987 The expectation given in an Expect header field (see <xref target="header.expect"/>) … … 1984 1995 <iref primary="true" item="426 Upgrade Required (status code)" x:for-anchor=""/> 1985 1996 <iref primary="true" item="Status Codes" subitem="426 Upgrade Required" x:for-anchor=""/> 1997 <x:anchor-alias value="426 (Upgrade Required)"/> 1986 1998 <t> 1987 1999 The request can not be completed without a prior protocol upgrade. This … … 2853 2865 but it cannot expect responses to always honor them. For example, the origin 2854 2866 server might not implement server-driven negotiation, or it might decide that 2855 sending a response that doesn't conform to them is better than sending a 4062856 (Not Acceptable) response.2867 sending a response that doesn't conform to them is better than sending a <x:ref>406 2868 (Not Acceptable)</x:ref> response. 2857 2869 </t> 2858 2870 <t> … … 2913 2925 </t> 2914 2926 <t> 2915 This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)2927 This specification defines the 300 (Multiple Choices) and <x:ref>406 (Not Acceptable)</x:ref> 2916 2928 status codes for enabling agent-driven negotiation when the server is 2917 2929 unwilling or unable to provide a varying response using server-driven … … 2993 3005 If an Accept header field is present in a request and none of the 2994 3006 available representations for the response have a media type that is 2995 listed as acceptable, the origin server &MAY; either 2996 h onor the Accept header field by sending a 406 (Not Acceptable)response3007 listed as acceptable, the origin server &MAY; either honor the Accept 3008 header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response 2997 3009 or disregard the Accept header field by treating the response as if 2998 3010 it is not subject to content negotiation. … … 3094 3106 available representations for the response have a character encoding that 3095 3107 is listed as acceptable, the origin server &MAY; either honor the 3096 Accept-Charset header field by sending a 406 (Not Acceptable)response or3108 Accept-Charset header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response or 3097 3109 disregard the Accept-Charset header field by treating the response as if 3098 3110 it is not subject to content negotiation. … … 3578 3590 If all received Expect header field(s) are syntactically valid but contain 3579 3591 an expectation that the recipient does not understand or cannot comply with, 3580 the recipient &MUST; respond with a 417 (Expectation Failed)status code. A3592 the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A 3581 3593 recipient of a syntactically invalid Expectation header field &MUST; respond 3582 3594 with a 4xx status code other than 417. -
draft-ietf-httpbis/latest/p6-cache.html
r1710 r1713 833 833 <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common 834 834 form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of 835 the resource identified by the request target. However, it is also possible to cache negative results (e.g., 404 not found), 836 incomplete results (e.g., 206 partial content), and responses to safe methods other than GET if the method's definition allows 837 such caching and defines something suitable for use as a cache key. 835 the resource identified by the request target. However, it is also possible to cache negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable 836 for use as a cache key. 838 837 </p> 839 838 <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching -
draft-ietf-httpbis/latest/p6-cache.xml
r1710 r1713 434 434 request: i.e., a 200 (OK) response containing a representation of the 435 435 resource identified by the request target. However, it is also possible 436 to cache negative results (e.g., 404 not found), incomplete results437 (e.g., 206 partial content), and responses to safe methods other than436 to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results 437 (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than 438 438 GET if the method's definition allows such caching and defines something 439 439 suitable for use as a cache key. … … 2288 2288 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 2289 2289 <x:source basename="p2-semantics" href="p2-semantics.xml"> 2290 <x:defines>404 (Not Found)</x:defines> 2290 2291 <x:defines>504 (Gateway Timeout)</x:defines> 2291 2292 </x:source> -
draft-ietf-httpbis/latest/p7-auth.html
r1708 r1713 449 449 } 450 450 @bottom-center { 451 content: "Expires January 4, 2013";451 content: "Expires January 5, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 3">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-04"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 4, 2013</td>522 <td class="left">Expires: January 5, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 3, 2012</td>527 <td class="right">July 4, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on January 4, 2013.</p>555 <p>This Internet-Draft will expire on January 5, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 715 715 a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy. 716 716 </p> 717 <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) 718 status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 717 <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 719 718 </p> 720 719 <p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional -
draft-ietf-httpbis/latest/p7-auth.xml
r1708 r1713 329 329 <t> 330 330 A server receiving credentials that are valid, but not adequate to gain 331 access, ought to respond with the 403 (Forbidden)status code (&status.403;).331 access, ought to respond with the <x:ref>403 (Forbidden)</x:ref> status code (&status.403;). 332 332 </t> 333 333 <t> … … 892 892 </front> 893 893 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 894 <x:source basename="p2-semantics" href="p2-semantics.xml" /> 894 <x:source basename="p2-semantics" href="p2-semantics.xml"> 895 <x:defines>403 (Forbidden)</x:defines> 896 </x:source> 895 897 </reference> 896 898
Note: See TracChangeset
for help on using the changeset viewer.