Changeset 2028


Ignore:
Timestamp:
03/12/12 15:45:25 (10 years ago)
Author:
fielding@…
Message:

Expand on message parsing robustness regarding whitespace.
Clarify that whitespace-delimited parsing by recipients is allowed.

Add requirement on recipients of whitespace between start-line and
first header field to be consistent with implementations and safe
from the header spoofing issues.

Reduce ABNF conformance by recipients to a SHOULD.

Addresses #411, #412, and #414.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2027 r2028  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 4, 2013";
     451       content: "Expires June 6, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-01">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-03">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 1, 2012</td>
     522               <td class="right">December 3, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 4, 2013</td>
     525               <td class="left">Expires: June 6, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </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>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    11401140         Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing.
    11411141      </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>
    11421146      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="request.line" href="#request.line">Request Line</a></h3>
    11431147      <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),
    … …  
    11581162      </p>
    11591163      <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&nbsp;3.5</a>).
    11611165      </p>
    11621166      <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 deliberately
     1167         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
    11641168         crafted to bypass security filters along the request chain.
    11651169      </p>
    … …  
    14921496      </p>
    14931497      <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
    14981508         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.
    15001510      </p>
    15011511      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2027 r2028  
    10481048   ignored by some clients or cause others to cease parsing.
    10491049</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>
    10501058
    10511059<section title="Request Line" anchor="request.line">
    … …  
    10851093   No whitespace is allowed inside the method, request-target, and
    10861094   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"/>).
    10881097</t>
    10891098<t>
    10901099   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.
    10931102   Recipients of an invalid request-line &SHOULD; respond with either a
    10941103   <x:ref>400 (Bad Request)</x:ref> error or a <x:ref>301 (Moved Permanently)</x:ref>
    … …  
    18011810   the server is reading the protocol stream at the beginning of a
    18021811   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.
    18061826</t>
    18071827<t>
    … …  
    18101830   receives a sequence of octets that does not match the HTTP-message
    18111831   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. 
    18131833</t>
    18141834</section>
Note: See TracChangeset for help on using the changeset viewer.