Changeset 1713 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 04/07/12 17:59:15 (10 years ago)
- File:
-
- 1 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
Note: See TracChangeset
for help on using the changeset viewer.