Ignore:
Timestamp:
Dec 3, 2012, 7:45:25 AM (7 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.

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.