A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the content. A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.
FastHTTP does not enforce this rule in the context of header names.
To see this for yourself, run this FastHTTP server, and send the following request:
GET / HTTP/1.1\r\n
Host: whatever\r\n
\rtest: test\r\n
\r\n
Its response, after base64-decoding the pieces, should look something like this:
From RFC 9112:
FastHTTP does not enforce this rule in the context of header names.
To see this for yourself, run this FastHTTP server, and send the following request:
Its response, after base64-decoding the pieces, should look something like this:
The
\r
at the beginning of the first header name is invalid, and should cause the message to be rejected.