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.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.