I verified that this release is generally functional and specifically that --experimental-transform-types
is working correctly. Thanks!
We ended up changing our webserver implementation to be more RFC compliant. Strictly speaking, this is not a curl bug (although the error message could certainly be improved...).
More info here: https://github.com/cockpit-project/cockpit/pull/19927
I've done some additional research. It happens when the --head
command-line option is used and the server returns a non-empty encoding with Transfer-Encoding: chunked
. MDN says:
Warning: A response to a HEAD method should not have a body. If it has one anyway, that body must be ignored
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD
which suggests that the server is behaving in a way it should not, but the bug is with curl for not ignoring it. The MDN article links the RFC which says something else:
The HEAD method is identical to GET except that the server MUST NOT send content in the response.
https://www.rfc-editor.org/rfc/rfc9110#HEAD
.... so, our bug?
I managed to bisect it to this commit: https://github.com/curl/curl/commit/d7b6ce64ce0ad787ad2ed3ee05c94938a6b4f551 which is not included in that PR (which never got merged) but (indeed, curiously) tags it as Closed in the commit message.
This breaks two distinct things for us (Cockpit project):
--unix
to stop working. OK, fair enough. --unix
was never a valid option (the correct spelling is --unix-socket
) and the change here is that the "partial match" feature was removed. Easy enough for us to fix, but that's surely going to hit other people as well.Use dbus-broker-34-1.fc39.
Drop a broken symlink in ~/.local/share/dbus-1/services/org.example.service
Logout and login to observe your session is completely broken.
rpm-ostree override replace FEDORA-2023-e664d047ad (ie: this update)
Reboot
Everything working fine again.
There's a new upstream release to address this issue: https://github.com/bus1/dbus-broker/releases/tag/v35
This update hosed my system pretty badly due to the presence of a dangling symlink in my home directory. I filed https://github.com/bus1/dbus-broker/issues/328 upstream.
Fixes fluidsynth -a pipewire
(upstream issue https://github.com/FluidSynth/fluidsynth/pull/1230)
No more QEMU DHCP fails with this one :) Thanks
Already being fixed upstream https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/95
This kernel contains a known regression to mount behaviour. See https://lore.kernel.org/linux-fsdevel/CAOYeF9UzK=oHCH6UcLgx5g5a_pQhMbnpnwd90oxAjN7LrmDytA@mail.gmail.com/