Re: libcurl(?) bug

On 2/9/21 2:11 PM, Christoph M. Becker wrote:
> On 09.02.2021 at 13:42, Tamas Papp wrote:
>
>> On 2/9/21 1:30 PM, Christoph M. Becker wrote:
>>>>     // NOK:
>>>>     curl_setopt($ch, CURLOPT_HTTPHEADER, array("Accept: /\r\n"));
>>> I don't think that CURLOPT_HTTPHEADERs are supposed to have a trailing
>>> CRLF.
>>
>> 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?
>  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>


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,

tamas