tusd icon indicating copy to clipboard operation
tusd copied to clipboard

Setting Upload-Offset directly to response

Open stefan-scheidewig opened this issue 3 years ago • 4 comments

The Upload-Offset header is a mandatory response header within the tus protocol. In a scenario using tusd as library by uploading and processing big files the client's request can be kept alive by writing to the ResponseWriter. Doing so would lead to an invalid response without the Upload-Offset header as the response was already written. For that reason it is crucial to directly write mandatory headers like this one to the response.

In general it would also be better for the using application to have a chance to directly write headers into the response in the synchronous callbacks.

stefan-scheidewig avatar Jun 03 '22 21:06 stefan-scheidewig

I do not fully understand your situation. How exactly are you handling requests? Do you capture them before they are passed to tusd and then use them to send additional data to the client? tusd is not designed for such request handling outside of its logic.

Are you not able to use the PreFinishResponseCallback for processing files? The response will not be send until this callback returns.

Acconut avatar Jun 17 '22 11:06 Acconut

We are using the blocking PreFinishResponseCallback to process the uploaded file, which can take longer. As it may can take longer we prevent the closing of the client connection by sending empty bytes in a certain interval to keep the connection alive. But when you write to the response the currently set headers will be sent. They cannot be set after that. So the best would be to set headers directly to the response. Also for the application called by the callback.

stefan-scheidewig avatar Jun 17 '22 11:06 stefan-scheidewig

Ok, I see what you are doing. PreFinishResponseCallback is not meant for handling long processing times because it cannot be resumed. If the connection to the client breaks, the client cannot obtain anymore the response that PreFinishResponseCallback provided. Files should be processed asynchronously instead of blocking the response to the PATCH request, if possible.

That's why I am hesitant to merge this PR. I do not want to encourage people to block responses for long durations.

Acconut avatar Jun 17 '22 12:06 Acconut

https://github.com/tus/tusd/pull/455 implements a solution with provides the values from the context, but does not cause the context to get cancelled.

Acconut avatar Jun 17 '22 12:06 Acconut