Skip to content

webdav: fix race caused by libsoup

Jakub Janků requested to merge jjanku/spice-gtk:fix-webdav-client into master

If we read 0 bytes from the phodav server, the client connection was closed by the server.

In that case, remove the client immediately, instead of waiting for the data to be written to the mux channel.

Fixes: https://lists.freedesktop.org/archives/spice-devel/2020-July/051765.html

I believe that the underlying issue, that is causing the described problems, is that libsoup closes the connection after each request although the webdav client wanted it to be persistant (keep-alive).

Filed an issue for libsoup: https://gitlab.gnome.org/GNOME/libsoup/-/issues/195

Additionally, spice-webdavd does not close the connection when it receives 0-size message for a given webdav client.

As a result, single webdav client can send multiple request using one connection to spice-webdavd, but in spice-gtk for each request a new client with the same id must be created.

This leads to basically a race condition when there's still the client with the given id in the hash table, but the connection was already closed by libsoup/phodav server. So a new client should be started but the old closed one is used. The write op then naturally fails with the following error and the request is lost:

../spice-gtk-0.38/src/channel-webdav.c:325 webdav-11:0: write failed: Stream is already closed

So check whether the output stream is closed before demuxing.

Also add some debug messages.

Signed-off-by: Jakub Janků jjanku@redhat.com

Merge request reports