Question: Tus Plugin response additional data.
See original GitHub issueHello,
We have an application using Uppy + Tus uploader plugin with an TUS Java server where we have an use case where we need to manage some aditional information in the client.
We need to be able to know the custom download url created for the uploaded file in the server, wich we can provide as a custom header (added with the appropiate CORS configuration in the server) or with custom metadata added to the Info object of the TUS Protocol.
Checking the Tus Plugin code, https://github.com/transloadit/uppy/blob/master/packages/%40uppy/tus/src/index.js#L159 i don’t see the way to be able to achieve what we need, because the return object managed in the plugin, associated to the upload complete event, only returns de uploadURI.
Is there a way to achieve our use case with the current implementation? If there’s no way, would you be open to pulll requests, to, let’s say, add a configuration parameter to provide a function to generate the uploadResp object in the optsTus.onSuccess method?
Something like:
optsTus.onSuccess = () => { var uploadResp = null; if(createUploadResptFunct){ uploadResp = createUploadRespFunct(upload); }else{ uploadResp= { uploadURL: upload.url } }
Thanks in advance.
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (6 by maintainers)
Thanks for the additional details. I am glad to read that this is not a blocking issue for you, if I understand correctly. We got a similar feature request in the tus-js-client repository directly (see tus/tus-js-client#166), so we are considering for a future release. However, we don’t have the resources to work on this right now, so there is no ETA available.
Thanks for your reply @Acconut.
Our usecase depends heavily on tus-js-client and uppy as you already pointed out. TUS on server already let us do what we want, that is populating custom headers when the file upload is completed.
The piece of the puzzle missing, for us, therefore my question, is if tus-js-client was capable of letting us read those custom headers. By you reply I understand, that currently there’s no mechanism for that.
Our propposal was focused on achieving that behaviour, on tus-js-client and Uppy, exactly on the event fired when the file upload has finished; that would let us propagate custom dowload urls generated on the server, custom ids generated on the server etc; just by reading the correct header. Answering your question, about wich headers should the client expose in wich moment, i think it could be configurable as arguments on the client, because it has to be known either at server config with the CORS management and therefore in the client, wich headers will be used.
This behaviour is of course non-blocking for us, but with little modificacions on tus-js-client api (and Uppy), i think it would be very benefitial for the whole product, since, in my opinion, it would make the client richer and more flexible.
Thanks again. KInd regards.