Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.
FastHTTP does not enforce this rule for \r (CR) and \x00 (NUL).
To see this for yourself, run this FastHTTP server, and send the following request:
GET / HTTP/1.1\r\n
Host: whatever\r\n
test: te\r\x00st\r\n
\r\n
The headers in its response, after base64-decoding, should look something like this:
From RFC 9110, section 5.5:
FastHTTP does not enforce this rule for
\r
(CR) and\x00
(NUL).To see this for yourself, run this FastHTTP server, and send the following request:
The headers in its response, after base64-decoding, should look something like this:
In order to comply with the RFC, the
\r
and\x00
within the last header value should have either