Add TUS creation-with-upload support

[PVince81]

Description

Whenever the server advertised the capability for creation-with-upload,
use it automatically for chunked uploads.

It is possible to override this and disable it by setting
uploadChunkDirect=false in config.json

Related Issue

None

Motivation and Context

How Has This Been Tested?

Manual test with latest reva

Screenshots (if appropriate):

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)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• debug ocis/reva issue
• add changelog

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[PVince81]

@jfd this is not working and returns a 400 error: cs3org/reva#710

Also I noticed that the tus-js-client is not sending the header Expect: 100-continue to receive early feedback. Not sure if we should hack it in by passing that header ourselves or expect the lib to do so in the future.

• investigate possibility for expect header => will happen later

[PVince81]

Upload works with this Reva PR: cs3org/reva#725

Now I found out that tus-js-client is not using a fingerprint for uploads that use "creation-with-upload", which means those will not be resumable if the initial POST failed. It will not be resumable because the client has no way of keeping track of this upload so it will not know where to send a HEAD request if the server already had data.

In the light of this, I think we should not merge this PR until the library is fixed to start tracking uploads earlier. The doc does say that this feature is currently experimental.

Now thinking, the library would not be able to track the download before it gets the "Location" header from the response. This means that the first POST MUST go through. I'm not sure if the "100-Continue", once implemented, would be able to return that header earlier before the payload is sent. A workaround for this would be to purposefully send a smaller chunk for the initial upload to increase the chance of it going through and quickly get access to the "Location" header.

@butonic thoughts ?

[PVince81]

As far as I could read, we cannot send additional headers from the server when sending the "100-continue" status code.

So the only way would be to decide to send a smaller chunk first to avoid wasting a request and then continuing with the rest in a subsequent request.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Vincent Petry seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[kulmann]

Version 2 of the tus-js-client has a lot of changes regarding the upload tracking / fingerprints. Worth to give this another try after a lib update.

[kulmann]

Thanks for the ideas. We'll have a look at the new tus-js-client 2.3.0 soonish. Added this PR for reference in this ticket, so that we can give it another try after the upgrade.