Ignore:
Timestamp:
Aug 31, 2011, 4:38:20 PM (8 years ago)
Author:
fielding@…
Message:

Clarify that parsing as octets is a MUST requirement (as already
implied by the ABNF) and explain the security issues, as well as
the point at which normal parsers can be used.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1420 r1424  
    11761176</t>
    11771177<t>
    1178    Care must be taken to parse an HTTP message as a sequence
    1179    of octets in an encoding that is a superset of US-ASCII.  Attempting
    1180    to parse HTTP as a stream of Unicode characters in a character encoding
    1181    like UTF-16 might introduce security flaws due to the differing ways
    1182    that such parsers interpret invalid characters.
     1178   Recipients &MUST; parse an HTTP message as a sequence of octets in an
     1179   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
     1180   Parsing an HTTP message as a stream of Unicode characters, without regard
     1181   for the specific encoding, creates security vulnerabilities due to the
     1182   varying ways that string processing libraries handle invalid multibyte
     1183   character sequences that contain the octet LF (%x0A).  String-based
     1184   parsers can only be safely used within protocol elements after the element
     1185   has been extracted from the message, such as within a header field-value
     1186   after message parsing has delineated the individual fields.
    11831187</t>
    11841188<t>
Note: See TracChangeset for help on using the changeset viewer.