Comments

22 Comments

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.

User Icon lis commented & provided feedback on curl-8.6.0-1.fc40 5 months ago
karma

This breaks two distinct things for us (Cockpit project):

  • this upstream change https://github.com/curl/curl/commit/07dd60c05b5f6b00ff7cc0d65c6b46cb1a6938a2 causes --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.
  • worse, though: there's a new "curl: (8) Failed reading the chunked-encoded stream" failure coming from our tests and it's not clear why. I've tried to reproduce this with various versions from upstream git, but have been unable to do so.
karma
  1. Use dbus-broker-34-1.fc39.

  2. Drop a broken symlink in ~/.local/share/dbus-1/services/org.example.service

  3. Logout and login to observe your session is completely broken.

  4. rpm-ostree override replace FEDORA-2023-e664d047ad (ie: this update)

  5. Reboot

  6. Everything working fine again.

karma

There's a new upstream release to address this issue: https://github.com/bus1/dbus-broker/releases/tag/v35

karma

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.

karma

Fixes fluidsynth -a pipewire (upstream issue https://github.com/FluidSynth/fluidsynth/pull/1230)

karma

No more QEMU DHCP fails with this one :) Thanks

karma

Very strong thumbs-down from me. Starting from a clean Fedora 34 install, and running the above dnf upgrade command results in my qemu-kvm VMs with usermode networking not able to get dhcp replies (and failing to configure their networking).

User Icon lis commented & provided feedback on fedora-repos-34-2 3 years ago
karma

archive repo is present...

User Icon lis commented & provided feedback on samba-4.14.3-0.fc34 3 years ago
karma

The upgrade is generally working, and the perl dependency is gone, but I can't follow the "desktop network smb" script because I keep getting messages about

$ smbtree -N
smbc_opendir: No such file or directory

and a very similar message from Nautilus when trying to browse the "Windows Network".

The ENOENT almost certainly refers to this problem, found with strace:

connect(8, {sa_family=AF_UNIX, sun_path="/run/samba/nmbd/unexpected"}, 110) = -1 ENOENT (No such file or directory)

and indeed, nmbd isn't running, and even appears not to be installed in Silverblue by default.

There seem to be some others complaining about that here: https://discussion.fedoraproject.org/t/cannot-browse-windows-shares-on-network-smbc-opendir-no-such-file-or-directory/27740

I'm not sure if this should be considered a bug, but in any case, it's not a regression introduced by this update, so +1 overall.

BZ#1949295 Please drop or split out findsmb script
BZ#1951531 samba-4.14.3 is available
karma

Me too.

dl.flathub.org  canonical name = dualstack.t2.shared.global.fastly.net.
Name:   dualstack.t2.shared.global.fastly.net
Address: 151.101.114.217
Name:   dualstack.t2.shared.global.fastly.net
Address: 2a04:4e42:1b::729

If I do a ping -6 dl.flathub.org followed by a ping -4 dl.flathub.org then the second one fails.

Wildly speculating: maybe the cache ends up with a result that only contains the v6 address, and when we try later to lookup the v4 address the cache replies "I know this address and it has no v4!" Or maybe it's something else entirely.