1. 22 Jul, 2020 1 commit
    • Jakub Janků's avatar
      webdav: fix race caused by libsoup · e4a5eb1d
      Jakub Janků authored
      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ů's avatarJakub Janků <jjanku@redhat.com>
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      e4a5eb1d
  2. 24 May, 2020 1 commit
  3. 23 May, 2020 1 commit
    • Kevin Pouget's avatar
      src/meson.build: fix bug when project version is unknown · c5e2ab43
      Kevin Pouget authored
      When `build-aux/git-version-gen` is not able to find the project
      version (no git tags and no `.tarball-version`), it returns 'UNKNOWN'
      or 'UNKNOWN-dirty' (instead of the project version like
      `0.38.28-d79b`).
      
      This `UNKNOWN` value fails `meson build` command:
      
          src/meson.build:9:0: ERROR: Index 1 out of bounds of array of size 1.
      
      With this patch, we set a default major/minor/micro value when the
      actual version is unknown. This is the same as the `autoconf`
      historical behavior.
      
      See spice#41.
      Signed-off-by: Kevin Pouget's avatarKevin Pouget <kpouget@redhat.com>
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      c5e2ab43
  4. 22 May, 2020 1 commit
  5. 15 May, 2020 1 commit
  6. 11 May, 2020 4 commits
  7. 06 May, 2020 1 commit
  8. 30 Apr, 2020 1 commit
  9. 26 Apr, 2020 1 commit
  10. 25 Apr, 2020 1 commit
  11. 24 Apr, 2020 3 commits
  12. 22 Apr, 2020 1 commit
  13. 16 Apr, 2020 2 commits
  14. 09 Apr, 2020 2 commits
  15. 07 Apr, 2020 4 commits
  16. 04 Apr, 2020 1 commit
  17. 20 Mar, 2020 1 commit
  18. 19 Mar, 2020 2 commits
  19. 17 Mar, 2020 3 commits
  20. 16 Mar, 2020 3 commits
  21. 10 Mar, 2020 5 commits