⚠️ Before posting ⚠️
Steps to reproduce
- Connect to a Wi-Fi network with limited/fluctuating upload bandwidth (in our case the link delivered 0.1-1.5 MB/s).
- Upload any file larger than ~10 MB from the Android app to a Nextcloud 34 server.
- The chunked upload fails; the app retries and keeps failing.
Expected behaviour
The upload should complete on slow links. The server already advertises files.chunked_upload.max_size via capabilities — the client could use it and pick a chunk size that fits the current throughput and the transfer timeout, so chunks finish well before the deadline.
Actual behaviour
ChunkedFileUploadRemoteOperation uses hardcoded chunk sizes - 40 MB on Wi-Fi (CHUNK_SIZE_WIFI), 10 MB on mobile (CHUNK_SIZE_MOBILE) - and never reads the server's files.chunked_upload.max_size. The client's read timeout is fixed at 60 s (DEFAULT_DATA_TIMEOUT in OwnCloudClientFactory). The server answers a chunk PUT only after the whole body arrives, so on a slow link the 60 s read timeout fires mid-transfer:
- client aborts the connection (proxy logs 499),
- server gets a truncated chunk and answers
400 BadRequest "chunk smaller than expected",
- upload fails and retries forever.
Android version
14
Device brand and model
Samsung Galaxy S24
Stock or custom OS?
Stock
Nextcloud android app version
34.1.0
Nextcloud server version
34.0.2
Using a reverse proxy?
Yes
Android logs
No response
Server error logs
{"reqId":"JR0L5n4PhFC9tmyDp5in","level":3,"time":"2026-08-12T19:14:47+03:00","user":"sonya","method":"PUT","url":"/remote.php/dav/uploads/sonya/<id>/000001","message":"Expected filesize of 40960000 but read (from Nextcloud client) and wrote (to Nextcloud storage) 13336576. Could either be a network problem on the sending side or a problem writing to the storage on the server side.","exception":"Sabre\DAV\Exception\BadRequest"}Additional information
Proposal for developers: size chunks dynamically instead of per connection type:
- respect
files.chunked_upload.max_size from capabilities (min(serverMax, ...)),
- target a chunk size that fits the measured throughput, e.g.
chunk = throughput * factor, keeping a sane floor,
- either scale the read timeout with the body size or skip the read deadline while the request body is still being written (
writeTimeout already covers sending; the read timeout is what kills the request here).
That way a slow link degrades to smaller resumable chunks instead of a guaranteed failure.
Steps to reproduce
Expected behaviour
The upload should complete on slow links. The server already advertises
files.chunked_upload.max_sizevia capabilities — the client could use it and pick a chunk size that fits the current throughput and the transfer timeout, so chunks finish well before the deadline.Actual behaviour
ChunkedFileUploadRemoteOperationuses hardcoded chunk sizes - 40 MB on Wi-Fi (CHUNK_SIZE_WIFI), 10 MB on mobile (CHUNK_SIZE_MOBILE) - and never reads the server'sfiles.chunked_upload.max_size. The client's read timeout is fixed at 60 s (DEFAULT_DATA_TIMEOUTinOwnCloudClientFactory). The server answers a chunk PUT only after the whole body arrives, so on a slow link the 60 s read timeout fires mid-transfer:400 BadRequest"chunk smaller than expected",Android version
14
Device brand and model
Samsung Galaxy S24
Stock or custom OS?
Stock
Nextcloud android app version
34.1.0
Nextcloud server version
34.0.2
Using a reverse proxy?
Yes
Android logs
No response
Server error logs
{"reqId":"JR0L5n4PhFC9tmyDp5in","level":3,"time":"2026-08-12T19:14:47+03:00","user":"sonya","method":"PUT","url":"/remote.php/dav/uploads/sonya/<id>/000001","message":"Expected filesize of 40960000 but read (from Nextcloud client) and wrote (to Nextcloud storage) 13336576. Could either be a network problem on the sending side or a problem writing to the storage on the server side.","exception":"Sabre\DAV\Exception\BadRequest"}Additional information
Proposal for developers: size chunks dynamically instead of per connection type:
files.chunked_upload.max_sizefrom capabilities (min(serverMax, ...)),chunk = throughput * factor, keeping a sane floor,writeTimeoutalready covers sending; the read timeout is what kills the request here).That way a slow link degrades to smaller resumable chunks instead of a guaranteed failure.