Segmented WebDAV upload

[serious-angel]

Dear Developers,

Thank you very much for the awesome project.

---

Is your feature request related to a problem? Please describe.

For example, a WebDAV server has a maximum upload size limit set to 512 MB. An upload of 1 GB file will result in an error on the server side like the following or similar: client intended to send too large body. The upload fails.

Describe the solution you'd like

What if either of these:

• A file bigger than set in the client settings is split to multiple small enough files named incrementally (e.g. f-00.zip.part, f-01.zip.part) and these are uploaded;
• HTTP Partial PUT client support.

Describe alternatives you've considered

Other protocols which support resume or segmented/buffer transfers, like SFTP/FTPS/FTP or BitTorrent.

Additional context

https://www.rfc-editor.org/rfc/rfc9110.html#section-14.4 (The "Content-Range" header field is sent in...)
https://www.rfc-editor.org/rfc/rfc9110.html#section-14.5 (Partial PUT...)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range (The Content-Range response HTTP header indicates where...)
https://stackoverflow.com/q/716680/5113030 (Difference between Content-Range and Range headers?...)

---

Best and kind regards

[dkocher]

Are you aware of a server implementation that supports partial PUT requests with Content-Range headers?

[serious-angel]

Are you aware of a server implementation that supports partial PUT requests with Content-Range headers?

I am sorry, but may you provide more insight? It seems the issue description includes a suggestion and references of the technology you mentioned. Perhaps more details will help!

[AliveDevil]

The HTTP Content-Range and Partial Put aren't supported on many Dav-servers, and there are conflicting implementations. Namely Apache mod_dav uses PUT with Content-Range header, and SabreDav (Nextcloud, Owncloud, and many others) use PATCH with X-Update-Range header - see rust webdav_handler^1.

[serious-angel]

The HTTP Content-Range and Partial Put aren't supported on many Dav-servers, and there are conflicting implementations. Namely Apache mod_dav uses PUT with Content-Range header, and SabreDav (Nextcloud, Owncloud, and many others) use PATCH with X-Update-Range header - see rust webdav_handler1.

Footnotes

1. https://docs.rs/webdav-handler/0.2.0-alpha.1/webdav_handler/#implemented-standards ↩

Thank you very much for the reference. It's known that it's completely up to a server, as also stated in the RFCs above. The question is should the client support at least either of these (e.g. Nextcloud on Nginx)?

P.S. Very nice reference design, @AliveDevil! Off-topic, but I am curious to ask how would you add a reference to your message which is not tied to any direct part of any sentence, but just an additional/contextual (without a number/index)?

Related:
https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/chunking.html (Nextcloud has a chunking API where you can upload smaller chunks...)
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html (Uploading big files > 512MB...)

[AliveDevil]

P.S. Very nice reference design, @AliveDevil! Off-topic, but I am curious to ask how would you add a reference to your message which is not tied to any direct part of any sentence, but just an additional/contextual (without a number/index)?

These are footnotes, as described in Markdown standard, and implemented by Github since September 2021 in comments^1.

Footnotes unfortunately don't work without direct reference, so you'd need [^1][^2][^3] at the end of your message, to include additional context.

[ArcticLampyrid]

The HTTP Content-Range and Partial Put aren't supported on many Dav-servers, and there are conflicting implementations. Namely Apache mod_dav uses PUT with Content-Range header, and SabreDav (Nextcloud, Owncloud, and many others) use PATCH with X-Update-Range header - see rust webdav_handler.

I believe that supporting these two approaches already covers many scenarios.

[joshtrichards]

Related: #10925

And, due to the lack of chunking, this one is more likely to occur: #15278