fix(dav): only derive the write size from a PUT Content-Length

[mosi-kha]

• Resolves: Chunked uploading - MOVE with Content-Length: 0 results in 0bytes files in Object Storage #63504
• Related: Chunked transfers lead to 0 byte files #7995

Summary

File::put() takes the expected write size from the request's Content-Length, but it is not reached only by PUT. The chunked upload assembly step is a MOVE (or COPY) of <upload>/.file: Directory::moveInto() and Directory::copyInto() only short-circuit File and Directory sources at storage level, so a FutureFile falls through to Tree::copyNode() → Directory::createFile() → File::put(). There the data is the AssemblyStream of the uploaded chunks and the request itself carries no body at all, so its Content-Length describes nothing relevant.

$lengthHeader = $this->request->getHeader('content-length');
$expected = $lengthHeader !== '' ? (int)$lengthHeader : null;
...
$count = $partStorage->writeStream($internalPartPath, $wrappedData, $expected);

Clients that send Content-Length: 0 on that request — Safari does, Chrome omits the header entirely — make $expected 0 instead of null. ObjectStoreStorage::writeStream() only measures the stream when it is given no size:

public function writeStream(string $path, $stream, ?int $size = null): int {
	if ($size === null) {
		$stats = fstat($stream);
		...

so the fstat() fallback is skipped, $stat['size'] becomes 0, and the file is recorded as empty while the request still answers 201. The upload looks successful and the file is silently empty.

The size comparison further down in the same method is already restricted to PUT for exactly this reason:

if ($expected !== null
	&& $expected !== $count
	&& $this->request->getMethod() === 'PUT'
) {

This applies the same restriction when deriving the expected size in the first place. Because the guard is on the method rather than on the value, it covers the COPY variant as well as MOVE — a fix that special-cased a zero length, or only MOVE, would not.

Genuine empty PUT uploads are unaffected: the method is still PUT, so a Content-Length of 0 is passed through exactly as before.

Scope

Object-storage primary storage is affected. OC\Files\Storage\Local::writeStream() ignores the $size argument entirely and just calls file_put_contents(), so local-storage installs should not be.

Methods that reach File::put():

method	reaches put()	data written	Content-Length meaningful
PUT	yes, CorePlugin::httpPut	the request body	yes
MOVE of <upload>/.file	yes	AssemblyStream	no
COPY of <upload>/.file	yes	AssemblyStream	no
MOVE/COPY of a normal file	no, handled at storage level	—	—

Testing

FileTest::testPutExpectedSizeOnlyComesFromPutContentLength covers the size handed to writeStream() for PUT (with a length, with 0, and with the header absent) and for MOVE/COPY (with 0 and with a non-zero length).

Against master without the change, 4 of the 7 cases fail:

...FFFF                                                             7 / 7 (100%)

1) ... with data set "MOVE ignores a zero length" ('MOVE', ['0'], null)
Failed asserting that 0 is identical to null.
2) ... with data set "MOVE ignores a non-zero length" ('MOVE', ['9'], null)
Failed asserting that 9 is identical to null.
3) ... with data set "COPY ignores a zero length" ('COPY', ['0'], null)
Failed asserting that 0 is identical to null.
4) ... with data set "COPY ignores a non-zero length" ('COPY', ['9'], null)
Failed asserting that 9 is identical to null.

FAILURES!
Tests: 7, Assertions: 13, Failures: 4

With the change, Tests: 7, Assertions: 21, all passing.

Verified end to end as well, on 33.0.7 with nginx + php-fpm and S3 (MinIO) primary storage, using a 102 395 904 byte file in five chunks. Adding Content-Length: 0 to the assembly request is the only variable that breaks it, for both MOVE and COPY, sequentially or in parallel.

Optional hardening, not included here

@vpecinka independently diagnosed this in #7995 (comment) and patched the storage layer instead, forcing $size = null in ObjectStoreStorage::writeStream() when a zero is announced for a stream that fstat() shows is larger. That defends against any other caller passing a bogus zero, which this change does not.

It is deliberately left out to keep this PR to the root cause; writeStream() putting the announced size straight into the filecache is arguably worth guarding on its own. Happy to add it here or as a separate PR if you would prefer it.

Checklist

• Code is properly formatted (php-cs-fixer reports no changes for both files)
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes) — happy to request these, say which branches
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[susnux]

/backport to stable35

[susnux]

/backport to stable34

[susnux]

/backport to stable33

[susnux]

/backport to stable34

[backportbot]

The backport to stable34 failed. Please do this backport manually.

# Switch to the target branch and update it
git checkout stable34
git pull origin stable34

# Create the new backport branch
git checkout -b backport/63510/stable34

# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts, resolve them
git cherry-pick 7a4714ad

# Push the cherry pick commit to the remote repository and open a pull request
git push origin backport/63510/stable34

Error: Failed to create pull request: Validation Failed: {"resource":"PullRequest","code":"custom","message":"A pull request already exists for nextcloud:backport/63510/stable34."} - https://docs.github.com/rest/pulls/pulls#create-a-pull-request

---

Learn more about backports at https://docs.nextcloud.com/server/stable/go.php?to=developer-backports.

[susnux]

/backport to stable32

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)