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

Setting Upload-Offset directly to response #741

Closed

Conversation

stefan-scheidewig
Copy link

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.

@Acconut
Copy link
Member

Acconut commented Jun 17, 2022

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.

@stefan-scheidewig
Copy link
Author

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.

@Acconut
Copy link
Member

Acconut commented Jun 17, 2022

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
Copy link
Member

Acconut commented Jun 17, 2022

#455 implements a solution with provides the values from the context, but does not cause the context to get cancelled.

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

Successfully merging this pull request may close these issues.

2 participants