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