search

tus / tus-resumable-upload-protocol

Open Protocol for Resumable File Uploads
https://tus.io
MIT License
1.48k stars 103 forks source link

Add extension to allow for discovery of existing upload URL #194

Closed dkocher closed 5 months ago

dkocher commented 7 months ago

Currently client implementations must persist the Upload URL. I propose an extension that allows the discovery of existing upload URLs for unfinished uploads based on metadata. Similar to ListMultipartUploads ^1 in S3.

Acconut commented 7 months ago

Could you elaborate a bit more on concrete use cases? In what scenarios would the client not be able to persist upload URLs but still be interested in resuming uploads?

dkocher commented 6 months ago

Could you elaborate a bit more on concrete use cases? In what scenarios would the client not be able to persist upload URLs but still be interested in resuming uploads?

We are discussing an implementation in Cyberduck ^1. In this use case the user might abort an upload. The extension to discover an existing upload URLs for a filename would allow to prompt the user to resume a transfer that is initiated later with no context of the previous action.

Acconut commented 6 months ago

The client application usually keeps track of which uploads it started and didn't finish. For example, tus-js-client automatically persists information about the uploads in a device-local storage. Once the application wants to resume an upload, it can query this storage for related uploads and resume accordingly. Upload resumption will usually be performed by the same device that created the upload because typically the file isn't available magically on another device. This removes the need for a server to look up which uploads are available for resumption.

Is there a specific reason why you don't want to use device-local storage?

dkocher commented 5 months ago

My intention was to allow for easier client implementations without the requirement for storage. Looking at the overall picture I agree keeping the protocol lean should probably be the priority instead. The use case with different devices and/or client applications uploading the same file is probably not a common concern.