fixes #388

[tim3trick]

Responses to the pre-finish hook will be passed to the client as custom header "X-pre-finish-response"

[Acconut]

Thank you for the PR but I see a two problems withthis approach:

1. This is a breaking API change since the PreFinishCallback's signature changed.
2. Calling the header X-pre-finish-response is not a good fit. It exposes implementation details of tusd (i.e. that tusd uses hooks internally and that a pre-finish hook provided this value) which are not relevant to the world outside of tusd. Also, I can image a situation where people would like to change the header's name.

What do you think?

[tim3trick]

Thank you for your response,

1. I agree, maybe it could be moved to yet another hook, that is built for this specific requirement? (Beside from just bumping the major version)

2. I agree again. How about describing an interface like
   {"header": "x-my-custom-header", "content": any content} and make tusd send the header (maybe after checking the name not to collide with tusds headers) with the given content?

When going with a new hook, how could that hook be named? pre-response?

[Acconut]

I am not sure I understand the idea of the pre-response hook here. When should it be invoked? Before every response that is sent by tusd?

[tim3trick]

My usecase is that I have to pass data to the client, which is basically based on the file itself, so I have to pass data as soon as the upload is complete (and before the connection to tusd is closed obviously). My usecase would be satisfied when the hook is called once (the pre-finish hook would be/is a perfect fit), right before everything is finished. For a broader usecase it could be a hook that is called each time before data is sent to the client and I build the hook to do nothing except for the last time, but as the hook should be blocking, this could add up to some serious delay...

[Acconut]

My usecase is that I have to pass data to the client

I can understand the need for that. However, tus and therefore tusd (especially the hook system) has been designed with uni-directional data flow from the client to the server and not vice versa. That's why tusd has no such feature yet and I am unsure if there is good/elegant solution to implement data flow from hooks to the client at the current time. I have ideas to rework the hook system to be more powerful but there is no timeline yet.

For a broader usecase it could be a hook that is called each time before data is sent to the client and I build the hook to do nothing except for the last time, but as the hook should be blocking, this could add up to some serious delay...

Yes, those delays sound like a serious problem and I would like to avoid that.

[Acconut]

The v2 release will contain features to customize the response from tusd and set a custom body and headers: #672