Changeset 2028
- Timestamp:
- 03/12/12 15:45:25 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2027 r2028 449 449 } 450 450 @bottom-center { 451 content: "Expires June 4, 2013";451 content: "Expires June 6, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 1">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-03"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 1, 2012</td>522 <td class="right">December 3, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 4, 2013</td>525 <td class="left">Expires: June 6, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 4, 2013.</p>553 <p>This Internet-Draft will expire on June 6, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1140 1140 Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. 1141 1141 </p> 1142 <p id="rfc.section.3.1.p.5">A recipient that receives whitespace between the start-line and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore 1143 the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received 1144 or the header block is terminated). 1145 </p> 1142 1146 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="request.line" href="#request.line">Request Line</a></h3> 1143 1147 <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), … … 1158 1162 </p> 1159 1163 <p id="rfc.section.3.1.1.p.8">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line 1160 into its component parts by splitting on the SP characters.1164 into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section 3.5</a>). 1161 1165 </p> 1162 1166 <p id="rfc.section.3.1.1.p.9">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters 1163 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 <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 deliberately1167 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 1164 1168 crafted to bypass security filters along the request chain. 1165 1169 </p> … … 1492 1496 </p> 1493 1497 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if the server is reading the protocol 1494 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend 1495 that recipients recognize a single LF as a line terminator and ignore any CR. 1496 </p> 1497 <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 1498 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. 1499 </p> 1500 <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR. 1501 </p> 1502 <p id="rfc.section.3.5.p.4">Although the request-line and status-line grammar rules require that each of the component elements be separated by a single 1503 SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as 1504 the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: 1505 SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. 1506 </p> 1507 <p id="rfc.section.3.5.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request 1498 1508 message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed 1499 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.1509 above, the server <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response. 1500 1510 </p> 1501 1511 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2027 r2028 1048 1048 ignored by some clients or cause others to cease parsing. 1049 1049 </t> 1050 <t> 1051 A recipient that receives whitespace between the start-line and 1052 the first header field &MUST; either reject the message as invalid or 1053 consume each whitespace-preceded line without further processing of it 1054 (i.e., ignore the entire line, along with any subsequent lines preceded 1055 by whitespace, until a properly formed header field is received or the 1056 header block is terminated). 1057 </t> 1050 1058 1051 1059 <section title="Request Line" anchor="request.line"> … … 1085 1093 No whitespace is allowed inside the method, request-target, and 1086 1094 protocol version. Hence, recipients typically parse the request-line 1087 into its component parts by splitting on the SP characters. 1095 into its component parts by splitting on whitespace 1096 (see <xref target="message.robustness"/>). 1088 1097 </t> 1089 1098 <t> 1090 1099 Unfortunately, some user agents fail to properly encode hypertext 1091 references that have embedded whitespace, sending the characters 1092 directly instead of properly percent-encoding the disallowed characters.1100 references that have embedded whitespace, sending the characters directly 1101 instead of properly encoding or excluding the disallowed characters. 1093 1102 Recipients of an invalid request-line &SHOULD; respond with either a 1094 1103 <x:ref>400 (Bad Request)</x:ref> error or a <x:ref>301 (Moved Permanently)</x:ref> … … 1801 1810 the server is reading the protocol stream at the beginning of a 1802 1811 message and receives a CRLF first, it &SHOULD; ignore the CRLF. 1803 Likewise, although the line terminator for the start-line and header 1804 fields is the sequence CRLF, we recommend that recipients recognize a 1805 single LF as a line terminator and ignore any CR. 1812 </t> 1813 <t> 1814 Although the line terminator for the start-line and header 1815 fields is the sequence CRLF, recipients &MAY; recognize a 1816 single LF as a line terminator and ignore any preceding CR. 1817 </t> 1818 <t> 1819 Although the request-line and status-line grammar rules require that each 1820 of the component elements be separated by a single SP octet, recipients 1821 &MAY; instead parse on whitespace-delimited word boundaries and, aside 1822 from the CRLF terminator, treat any form of whitespace as the SP separator 1823 while ignoring preceding or trailing whitespace; 1824 such whitespace includes one or more of the following octets: 1825 SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. 1806 1826 </t> 1807 1827 <t> … … 1810 1830 receives a sequence of octets that does not match the HTTP-message 1811 1831 grammar aside from the robustness exceptions listed above, the 1812 server & MUST; respond with an HTTP/1.1<x:ref>400 (Bad Request)</x:ref> response.1832 server &SHOULD; respond with a <x:ref>400 (Bad Request)</x:ref> response. 1813 1833 </t> 1814 1834 </section>
Note: See TracChangeset
for help on using the changeset viewer.