1. 19 Aug, 2020 4 commits
  2. 12 Aug, 2020 12 commits
  3. 07 Aug, 2020 1 commit
  4. 04 Aug, 2020 1 commit
  5. 22 Jul, 2020 1 commit
    • Jakub Janků's avatar
      webdav: fix race caused by libsoup · e4a5eb1d
      Jakub Janků authored and Frediano Ziglio's avatar Frediano Ziglio committed
      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: default avatarJakub Janků <jjanku@redhat.com>
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      e4a5eb1d
  6. 24 May, 2020 1 commit
  7. 23 May, 2020 1 commit
  8. 22 May, 2020 1 commit
  9. 15 May, 2020 1 commit
  10. 11 May, 2020 4 commits
  11. 06 May, 2020 1 commit
  12. 30 Apr, 2020 1 commit
  13. 26 Apr, 2020 1 commit
  14. 25 Apr, 2020 1 commit
  15. 24 Apr, 2020 3 commits
  16. 22 Apr, 2020 1 commit
  17. 16 Apr, 2020 2 commits
  18. 09 Apr, 2020 2 commits
  19. 07 Apr, 2020 1 commit