Changeset 2257 for draft-ietf-httpbis
- Timestamp:
- 19/05/13 19:13:12 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2253 r2257 1166 1166 <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>. 1167 1167 </p> 1168 <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line 1169 into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section 3.5</a>). 1170 </p> 1171 <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 1172 directly instead of properly encoding or excluding 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 <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> 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 1168 <p id="rfc.section.3.1.1.p.7">Recipients typically parse the request-line into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section 3.5</a>), since no whitespace is allowed in the three components. Unfortunately, some user agents fail to properly encode or exclude 1169 whitespace found in hypertext references, resulting in those disallowed characters being sent in a request-target. 1170 </p> 1171 <p id="rfc.section.3.1.1.p.8">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 <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> 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 1173 1172 crafted to bypass security filters along the request chain. 1174 1173 </p> … … 1620 1619 <p id="rfc.section.4.1.2.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p> 1621 1620 <div id="rfc.figure.u.34"></div><pre class="text"> length := 0 1622 read chunk-size, chunk-ext (if any) and CRLF1621 read chunk-size, chunk-ext (if any), and CRLF 1623 1622 while (chunk-size > 0) { 1624 1623 read chunk-data and CRLF 1625 1624 append chunk-data to decoded-body 1626 1625 length := length + chunk-size 1627 read chunk-size and CRLF1626 read chunk-size, chunk-ext (if any), and CRLF 1628 1627 } 1629 1628 read header-field … … 2088 2087 <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2089 2088 </p> 2090 <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connectionafter it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2091 </p> 2092 <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connectionafter it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2089 <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2090 </p> 2091 <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2093 2092 </p> 2094 2093 <p id="rfc.section.6.6.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; … … 2101 2100 can be read and interpreted by the client's HTTP parser. 2102 2101 </p> 2103 <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the2104 read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client2105 or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing2106 the server's last response. It is then safe for the server to fully closethe connection.2102 <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by 2103 closing only the write side of the read/write connection. The server then continues to read from the connection until it receives 2104 a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's 2105 acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection. 2107 2106 </p> 2108 2107 <p id="rfc.section.6.6.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2253 r2257 1088 1088 </t> 1089 1089 <t> 1090 No whitespace is allowed inside the method, request-target, and 1091 protocol version. Hence, recipients typically parse the request-line 1092 into its component parts by splitting on whitespace 1093 (see <xref target="message.robustness"/>). 1094 </t> 1095 <t> 1096 Unfortunately, some user agents fail to properly encode hypertext 1097 references that have embedded whitespace, sending the characters directly 1098 instead of properly encoding or excluding the disallowed characters. 1090 Recipients typically parse the request-line into its component parts by 1091 splitting on whitespace (see <xref target="message.robustness"/>), since 1092 no whitespace is allowed in the three components. 1093 Unfortunately, some user agents fail to properly encode or exclude 1094 whitespace found in hypertext references, resulting in those disallowed 1095 characters being sent in a request-target. 1096 </t> 1097 <t> 1099 1098 Recipients of an invalid request-line &SHOULD; respond with either a 1100 1099 <x:ref>400 (Bad Request)</x:ref> error or a <x:ref>301 (Moved Permanently)</x:ref> … … 2021 2020 <figure><artwork type="code"> 2022 2021 length := 0 2023 read chunk-size, chunk-ext (if any) and CRLF2022 read chunk-size, chunk-ext (if any), and CRLF 2024 2023 while (chunk-size > 0) { 2025 2024 read chunk-data and CRLF 2026 2025 append chunk-data to decoded-body 2027 2026 length := length + chunk-size 2028 read chunk-size and CRLF2027 read chunk-size, chunk-ext (if any), and CRLF 2029 2028 } 2030 2029 read header-field … … 3028 3027 <t> 3029 3028 A server that receives a <x:ref>close</x:ref> connection option &MUST; 3030 initiate a lingering close (see below) of the connectionafter it sends the3029 initiate a close of the connection (see below) after it sends the 3031 3030 final response to the request that contained <x:ref>close</x:ref>. 3032 3031 The server &SHOULD; send a <x:ref>close</x:ref> connection option … … 3036 3035 <t> 3037 3036 A server that sends a <x:ref>close</x:ref> connection option &MUST; 3038 initiate a lingering close of the connectionafter it sends the3037 initiate a close of the connection (see below) after it sends the 3039 3038 response containing <x:ref>close</x:ref>. The server &MUST-NOT; process 3040 3039 any further requests received on that connection. … … 3058 3057 </t> 3059 3058 <t> 3060 To avoid the TCP reset problem, a server can perform a lingering close on a3061 connection by closing only the write side of the read/write connection3062 (a half-close) and continuing to read from the connection until the3063 connection is closed by the client or the server is reasonably certain3064 that its own TCP stack has received the client's acknowledgement of the3065 packet(s) containing the server's last response. It is then safe for the3066 server to fully closethe connection.3059 To avoid the TCP reset problem, servers typically close a connection in 3060 stages. First, the server performs a half-close by closing only the write 3061 side of the read/write connection. The server then continues to read from 3062 the connection until it receives a corresponding close by the client, or 3063 until the server is reasonably certain that its own TCP stack has received 3064 the client's acknowledgement of the packet(s) containing the server's last 3065 response. Finally, the server fully closes the connection. 3067 3066 </t> 3068 3067 <t>
Note: See TracChangeset
for help on using the changeset viewer.