search

tus / tus-resumable-upload-protocol

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

Location: response valid with PATCH response? #155

Closed nigoroll closed 4 years ago

nigoroll commented 4 years ago

I am working on a varnish cache vmod implementation of a TUS proxy, acting as a TUS server towards clients, to be released as open source. One particular aspect of the use case of the initial sponsor of this implementation is to always store objects with their content hash as the last path element.

Determining the hash is possible at creation time for POSTs

Yet with PATCH, the location of the object would change with every uploaded chunk (except for an empty one), so I wonder if updating it by sending a Location: response header would be allowed by the protocol. My take is that as PATCH is serialized by design, the protocol could require clients to accept updates to the location, but I have not found any mention of this case and would thus appreciate clarification.

nigoroll commented 4 years ago

shortly after posting this question, I realized that the client might not receive the server's response to a partial (interrupted) PATCH upload, so the Location would be changed to a value unknown to the client. I guess this answers my question in the sense that Location must not be changed after the initial creation, but I will leave the ticket open for a bit.

Acconut commented 4 years ago

shortly after posting this question, I realized that the client might not receive the server's response to a partial (interrupted) PATCH upload, so the Location would be changed to a value unknown to the client. I guess this answers my question in the sense that Location must not be changed after the initial creation

Exactly, you came to the right conclusion :) When dealing with unreliable networks you need to have a constant endpoint that does not change to synchronize the client's and server's progress. So changing URLs are not possible with the current design of tus.

nigoroll commented 4 years ago

thank you for the quick response!

nigoroll commented 4 years ago

I'd like to come back to this please once more: Yes, we can not change the upload location after the initial POST. Yet once the upload is complete, I think we could send a Location: response with a new, permanent URL: For the final PATCH, the client would either receive the Location: or miss it. In case it misses it, it would issue another OPTIONS / HEAD and then receive a) the info that the object is complete and b) the Location:. Would this make sense, @Acconut ?

Acconut commented 4 years ago

Yes, it does make sense. But to be honest, this sounds very application-specific and I am not sure this is a good fit for the specification in general.

nigoroll commented 4 years ago

I would not think support for content based URLs was particularly specific. It is a generally useful concept to implement de-duplication on the object level. Support for a late Location: change would also enable other uses where the final location depends on the content. I could imagine naming files by type, for example, or selecting paths by size.

Acconut commented 4 years ago

That's a good argument. Feel free to open a PR for this, if you want to :)