Re: Disallow newlines in CURLOPT_HTTPHEADER

From: Date: Thu, 09 Jul 2026 11:10:02 +0000
Subject: Re: Disallow newlines in CURLOPT_HTTPHEADER
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-131835@lists.php.net to get a copy of this message
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

« previous php.internals (#131835) next »