Re: libcurl(?) bug
| From: | Tamas Papp | Date: | Tue, 09 Feb 2021 18:48:36 +0000 |
| Subject: | Re: libcurl(?) bug | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-327484@lists.php.net to get a copy of this message | ||
On 2/9/21 2:11 PM, Christoph M. Becker wrote:
On 09.02.2021 at 13:42, Tamas Papp wrote:I'm not sure if php should strip CR and LF, but it's your call...for sure. I'm still wondering, why does it behaves differently with HTTP and HTTPS sites. Anyways, I will file bug. Thanks so much for you prompt attention. Cheers, tamasOn 2/9/21 1:30 PM, Christoph M. Becker wrote:From looking at the current PHP-7.4 implementation, these headers are forwarded to curl_easy_setopt() as is. The libcurl documentation of CURLOPT_HTTPHEADER[1] explicitly states: | The headers included in the linked list must not be CRLF-terminated, | because libcurl adds CRLF after each header item. Failure to comply | with this will result in strange bugs because the server will most | likely ignore part of the headers you specified. The only thing PHP could do here, would be to strip CR and LF from the passed headers; at least it could be documented that the headers must not be CRLF-terminated. Consider to file a bug report at <https://bugs.php.net/>. [1] <https://curl.se/libcurl/c/CURLOPT_HTTPHEADER.html>However, I agree with you on that, since it breaks a previously correctly working code, it still looks like a bug. Unless the backward compatibility intentionally should not be kept for any reason. Am I wrong?I don't think that CURLOPT_HTTPHEADERs are supposed to have a trailing CRLF.// NOK: curl_setopt($ch, CURLOPT_HTTPHEADER, array("Accept: /\r\n"));