A Single LF Line Terminator in RFC 9112

[Catminusminus]

RFC 9112 says:

Although the line terminator for the start-line and fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.

However, using a single LF as a line terminator can cause a HTTP request smuggling. In fact, Node.js had the vulnerability as CVE-2022-32214 and now it returns 400 Bad Request if it receives a suspicious request. See @zeyu2001's report (https://hackerone.com/reports/1524692 ) for details.

In addition, Waitress, a Python WSGI server had the vulnerability (https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p ). I suspect that even more software may be vulnerable.

The root cause seems the RFC. A server can use a single LF as a line terminator or not. And using the both servers causes a HTTP request smuggling.

Suggestions:

• Prohibit to use a single LF as a line terminator
• Contrary to the above, change the term MAY to MUST in the sentence

[reschke]

I'm not sure (yet).

A server that accepts the bare LF as delimiter is correct per spec, and that part of the spec has been stable for ages.

A servert that considers the LF as part of the field value on the other hand is ignoring a nornative requirement to to either reject the message, or convert to SP.

[Catminusminus]

Sorry for closing the issue by mistake.

A server that accepts the bare LF as delimiter is correct per spec, and that part of the spec has been stable for ages.

Yes, you are right.

A servert that considers the LF as part of the field value on the other hand is ignoring a nornative requirement to to either reject the message, or convert to SP.

I think this requirement is not about a single LF, but about a bare CR.

The RFC says "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."

Or am I missing the relevant part?

[zeyu2001]

Since I was mentioned, I should add that an LF is not a valid character in a header field value.

Therefore, it is not spec-compliant if a server delimits lines by CRLF and accepts an LF as part of a header value.

A downstream server can, however, be aware of the risks of a non-compliant upstream proxy and as an additional hardening measure, accept strictly CRLF only as line endings.

[Catminusminus]

Sorry I did not take RFC 9110 into consideration.

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.

Thank you very much for your response @zeyu2001 @reschke.