Desktop: Lots of bogus error messages "Wrong HTTP code"

[tribut]

Expected behaviour

The sync should finish without errors.

Actual behaviour

When many files are changed at once (such as moving about 1000 files just now), I regularly get the error Wrong HTTP code returned by server. Expected 201, but received "0 " in the client. There are no errors logged on the server and Apache only ever sees one request for each filename, which is listed with code 201 in the access log. The renames work.

Steps to reproduce

1. Rename lots of files (though I'm not sure this is the cause - it just happens to reproduce the problem for me)
2. Observe error messages in client
3. Notice that renames on the server where successful anyway

Client configuration

Client version: 2.5.1git

Operating system: Ubuntu 18.10

OS language: en-us

Qt version used by client package (Linux only, see also Settings dialog): 5.11.1

Client package (From Nextcloud or distro) (Linux only): Nextcloud

Installation path of client: Via apt

Server configuration

Operating system: Debian

Web server: Apache 2.4

Database: MariaDB 10.1

PHP version: 7.2

Nextcloud version: 15.0.4

Storage backend (external storage): n/a

Logs

Portion of nextcloud --logdebug surrounding IMG-20180511-WA0000.jpg: https://gist.github.com/tribut/84cf9af5670c318f21f7535014de98ce

In the web server access log, this is the only request to that file:

```
"MOVE /remote.php/dav/files/username/SofortUpload/WhatsApp%20Images/IMG-20180511-WA0000.jpg HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Linux) mirall/2.5.1git (Nextcloud)"

[ukos-git]

I just experienced the same error using nginx as server when renaming more than 1k files at a time. The server is located in the local network, the sync is continuing to sync without errors afterward.

Client version: 2.6.1git
Nextcloud version: Nextcloud 16.0.3
nginx version 1.14.0

[Aldaris1985]

Same issue for me too after deleting a lot of files that are synced.

Client version: 2.6.5
Nextcloud version: Nextcloud 17.0.8

[er-vin]

There's been change in that area, could someone test with 2.7.0-rc1 and let us know how this goes?

Also logs obtained with --logdebug and --logfile would be useful if that reproduces on 2.7.0-rc1.

[Aldaris1985]

There's been change in that area, could someone test with 2.7.0-rc1 and let us know how this goes?

Also logs obtained with --logdebug and --logfile would be useful if that reproduces on 2.7.0-rc1.

Thanks! Using 2.7.0-rc1 solved the issue for me.

[er-vin]

OK, thanks for letting us know, I'll close it then.