Hi
On 2026-07-09 12:49, Matteo Beccati wrote:
Il 09/07/2026 10:17, Sjoerd Langkemper ha scritto:
This is not supported behavior by cURL, and it is a security risk when
a header value is under control of an attacker: they can inject
arbitrary headers to the request.
I propose to not allow newlines in header values. Any thoughts on
this? Should this first raise a deprecation warning before throwing a
value error? I haven't added this to the deprecation RFC as I thought
that is being finalized and made ready for voting soon.
"\r\n" inside headers used to be perfectly legal for multiline headers.
This is not correct. What was legal was the sequence "\r\n" followed *by
either a space or a tab*. And it is equivalent to just a space. The
newlines are not “visible” in the parsed value. There is literally zero
reason to emit the obsolete line-folding syntax nowadays. As far as I
can tell it only existed due to considerations regarding the length of a
single line.
It is now obsolete, but I'm not sure why we should prevent it, if curl
does not.
Curl specifically documents:
The headers included in the linked list must not be CRLF-terminated,
since libcurl adds CRLF after each header item itself. Failure to
comply with this might result in strange behavior. libcurl passes on
the verbatim strings you give it, without any filter or other safe
guards. That includes white space and control characters.
Best regards
Tim Düsterhus
