Adding chunking capability

[DeepDiver1975]

Description

Related Issue

refs #25682

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

@ogoffart

[mention-bot]

@DeepDiver1975, thanks for your PR! By analyzing the history of the files in this pull request, we identified @PVince81, @rullzer and @LukasReschke to be potential reviewers.

[ogoffart]

In the client I have called it OC-If-Destination-Match (with the OC- prefix)
owncloud/client@c222793
But i realized I documented it without the OC-prefix in https://github.com/cernbox/smashbox/blob/master/protocol/chunking.md

I wonder if we should or not use the OC- prefix. What's the best practice in case of custom headers?

[ogoffart]

@evert any opinion about this header?

[evert]

If I understand this correctly, the If header already has this functionality

[DeepDiver1975]

If-match validates on the source. This header checks on the destination

[evert]

I'm talking about the If header, not If-Match. It can check lock tokens, etags and sync tokens on any arbitrary url

[evert]

Here's an example:

https://tools.ietf.org/html/rfc4918#section-7.5.1

[ogoffart]

@evert: thanks, that looks like exactly what we need, i did not know about it.

@DeepDiver1975 however, it seems that it's not working, because it's not rejecting erroring the MOVE in the final if i use the wrong ETAG. Is that supposed to work already?

[DeepDiver1975]

I'm talking about the If header, not If-Match. It can check lock tokens, etags and sync tokens on any arbitrary url

Sorry - took a while until I finally understood this 🙈 - I'll look into this - THX

[DeepDiver1975]

@DeepDiver1975 however, it seems that it's not working, because it's not rejecting erroring the MOVE in the final if i use the wrong ETAG. Is that supposed to work already?

yes - should 🙈

[ogoffart]

If i send:

MOVE /~owncloud/remote.php/dav/uploads/owncloud/4101267920/.file HTTP/1.1
Destination: /~owncloud/remote.php/dav/files/owncloud/big/file.ff
Content-Type: application/octet-stream
If: </~owncloud/remote.php/dav/files/owncloud/big/file.ff> ("garbage")
OC-Async: 1
X-OC-Mtime: 1476954084
[...]
Host: localhost

I get a 204 No Content and the file is correctly moved. I would expect an error!

[ogoffart]

Ah ok, my fault, i forgot the [ ] around the etag.

[DeepDiver1975]

If: </~owncloud/remote.php/dav/files/owncloud/big/file.ff> ("garbage")

this works already?

[ogoffart]

I had to use square bracket around the e-tag. (Reading the spec twice helps.)

If: </~owncloud/remote.php/dav/files/owncloud/big/file.ff> (["garbage"])

Alright. It seems everithing is working with the If header, and we don't need this.

Thanks @evert

[DeepDiver1975]

really awesome - I should spend more time reading the specs .....

@ogoffart we need this 82d238b for the capabilities

[evert]

I wonder if we should throw exceptions instead of ignoring broken If headers. The code for it is written a long time ago, and I never really looked back at it too much.

[DeepDiver1975]

@ogoffart do we agree on the capability?

[ogoffart]

yes, 👍

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.