Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[companion] tus uploads are always deferred #5560

Open
2 tasks done
dschmidt opened this issue Dec 20, 2024 · 1 comment · May be fixed by #5561
Open
2 tasks done

[companion] tus uploads are always deferred #5560

dschmidt opened this issue Dec 20, 2024 · 1 comment · May be fixed by #5561
Labels

Comments

@dschmidt
Copy link
Contributor

dschmidt commented Dec 20, 2024

Initial checklist

  • I understand this is a bug report and questions should be posted in the Community Forum
  • I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

Use companion to upload to a tus server without support for the https://tus.io/protocols/resumable-upload#upload-defer-length header (afaict implementing support for the header is optional).
ownCloud Infinite Scale for example does not implement it, c.f. owncloud/ocis#10794

It broke in #4697

Expected behavior

Upload works.

Actual behavior

It does not work and there does not seem to be a way to disable deferred length uploads.

@dschmidt
Copy link
Contributor Author

dschmidt commented Dec 21, 2024

If the Server supports deferring length, it MUST add creation-defer-length to the Tus-Extension header.

For oCIS it looks like this:

http --verify no OPTIONS https://host.docker.internal:9200/remote.php/dav/spaces/storage-users-1$some-admin-user-id-0000-000000000000
[…]
Tus-Extension: creation,creation-with-upload,checksum,expiration
[…]

The header is also available from error.originalRequest in the onError hook, so it would also be possible to detect the likely reason for the failure there, which seems to be a bit of a hacky way.

I'm not sure what the best approach is:
We could either try to detect upfront whether the extension is supported, so users don't need to know about this.
We could always assume it's supported and check after a failed request if the extension is missing and then retry without it...
Or we explicitly enable/disable it via Companion configuration as in my pull request, which saves some requests but offers more configuration surface and requires more knowledge from the user...
Or we introduce a tristate option: defer: yes/no/auto (the latter being an additional options request)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant