uhttpd allows CR and LF within header values

[kenballus]

From RFC 9110:

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.

uhttpd does not enforce this rule for CR and LF. This leads to a pretty poor interaction with certain load balancers. See litespeedtech/openlitespeed#394 for more details.

The suggested fix here would be to either

1. reject messages containing CR or LF within header values, or
2. replace those characters with spaces before processing the request.

[champtar]

The suggested fix here would be to either
1. reject messages containing CR or LF within header values, or
2. replace those characters with spaces before processing the request.

Don't try to sanitize, just reject, it's way safer

[kenballus]

Agreed.

[stokito]

I remember that curl on parsing response headers specifically allows any line ending. Is anything dangerous to do this from a client perspective?

[kenballus]

It would depend on the context. Permissiveness often has associated risk, but changing default behavior in a program as popular as curl can have serious unintended consequences. Not sure what the path forward is on the client side (if anything).