Since curl is built with libpsl, pecl_http test suite fails. This a tracker bug to not loose this. Upstream report (with curl upstream involved) libpsl: https://github.com/rockdaboot/libpsl/issues/48 pecl_http: https://github.com/m6w6/ext-http/issues/26 Perhaps we should revert this option for F24, waiting for a upstream fix.
To summarize, all non qualified domain (ex: "localhost") are considered by libpsl as "public suffix", and thus curl ignore the cookie. Add cicku, libpsl maintainer in CC.
(In reply to Remi Collet from comment #0) > Perhaps we should revert this option for F24, waiting for a upstream fix. Given the fact that we have not received any bug report except the php-pecl-http one, I do not think this is a major regression requiring an immediate revert. I would prefer to wait few more days to see whether the actual fix will go to libcurl or libpsl. Paul, what is your opinion on this? Should we revert the libpsl support now?
After digging a little in other applications using the libpsl, I think the usage in libcurl is not correct (so the bug is "in" curl, not in libpsl) The check should probably use psl_is_cookie_domain_acceptable instead of psl_is_public_suffix.
See http://git.savannah.gnu.org/cgit/wget.git/tree/src/cookies.c#n527
Thanks for digging! This is kind of surprising because the libcurl code your refer to is contributed by the libpsl maintainer: https://github.com/curl/curl/commit/e77b5b74
Also https://github.com/curl/curl/issues/658
(In reply to Kamil Dudka from comment #2) > (In reply to Remi Collet from comment #0) > > Perhaps we should revert this option for F24, waiting for a upstream fix. > > Given the fact that we have not received any bug report except the > php-pecl-http one, I do not think this is a major regression requiring an > immediate revert. I would prefer to wait few more days to see whether the > actual fix will go to libcurl or libpsl. > > Paul, what is your opinion on this? Should we revert the libpsl support now? I'm in favour of "wait and see" for the moment. The psl_is_cookie_domain_acceptable approach looks promising, as would allowing cookies for the same hostname as the HTTP host. I think it's likely that there will be a change in curl to address this anyway.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Could you please check whether curl-7.47.1-4.fc25 works good enough for you? http://koji.fedoraproject.org/koji/buildinfo?buildID=741218
See https://apps.fedoraproject.org/koschei/package/php-pecl-http Yes, curl-7.47.1-4.fc25 fix this issue. Thanks.
Thanks for confirmation! Fixed in curl-7.47.1-4.fc24.
upstream commit: https://github.com/curl/curl/commit/c140bd78