03/12/12 15:45:25 (8 years ago)

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.

1 edited


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

    r2027 r2028  
    10481048   ignored by some clients or cause others to cease parsing.
     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).
    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"/>).
    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.
     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.
     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.
    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. 
Note: See TracChangeset for help on using the changeset viewer.