uploading large files leads to 499

[shoeper]

While uploading large (almost 8GB) file via webdav I got this:

192.168.xxx.xxx -me@example.com [22/Jun/2015:20:23:48 +0200] "PUT /seafdav/tmp/Test/de_visual_studio_ultimate_2013_with_update_4_x86_dvd_5935076.iso HTTP/1.1" 499 0 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600"

which leads to

[2015-06-22 20:18:57,516]:  PUT: Content-Length == 0. Creating empty file...

Because we can not influence the client and windows did wait at least 30 seconds (which is quite much because at the same time the webdav windows isn't usable at all I have the following idea to fix this: add a background worker for webdav and process all files bigger than size x ever 30 seconds. It would work as follow:

• user uploads file
• if bigger smaller than x save to seafile and return
• if bigger than x save to tmp, add job to sql table and return
• backgroundworker looks up the sql table every x seconds and indexes new files, on finish it removes the job on error it adds a notification for the user who uploaded the file that the upload could not finish.

[shoeper]

Don't know if it is possible: Maybe once a file is uploaded it could spawn a new process, that keeps running no matter what happens, itself instead of using a worker.

[shoeper]

Adding this to nginx (seafdav block)

                # allow large file upload
                fastcgi_ignore_client_abort on;
                # kill after 30 Minutes
                fastcgi_read_timeout 30m;

improved the situation a bit, at least there was some file at the end. BUT it wasn't the whole file instead it was just a part of it (its not just an explorer bug or something similiar, I've checked checksums).

And I've also to say that server load was extremely high while uploading.

Edit: Uploading the same file via chrome does work fine. Upload speed was at 60MiB/s and after the file had been uploaded it took 3 minutes and few seconds to index it (which is acceptable). Unfortunately it did not work that great with WebDAV.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.