Add the Tus-Max-Size extension

[mitjap]

Closes #330

This PR is first step to support Tus-Max-Size extension. It limits amount of data uploaded to not exceed Upload-Length.

Current implementation does not wait for request stream to end. When limit is reached response successful response is sent back to the client which closes a socket. After receiving a response with status 204 client will also receive an error that connection was closed (indicating failed upload). This is similar to tusd behavior.
Alternative approach would be to wait for request stream to end and then send a response back to the client. This can lead to large delay between file being complete and response and potentially lots of data being uploaded that is just ignored. Upside is that no client error is reported.

Some test will need to be rewritten. When testing PATCH request it is now required that stream is passed to PatchHandler instead of just plain object with header property. I'll wait with this PR for TS migration (#308) to be finished. Meanwhile we have time for discussion.

We should discuss how the server should handle such scenario. Another option is to send a 413 (enitity too large) instead of 204.

So we need to decide:

• How to respond? (error or succes)
• When to respond? (immediately or delayed)

[Murderlon]

This PR is now ready to be worked on again. As for the approach, let's immediately respond with 413 if a PATCH request arrives with a Content-Length that exceeds the upload size.

[Murderlon]

@mitjap would you be willing to get this over the finish line soon?

[BlakeB415]

Any updates on this?

May I also suggest a way to set this limit on a per-upload basis using hooks?

[mitjap]

@Murderlon @Acconut Sorry for the delay. I'm still not sure when I'll be able to finish this. But don't lose hope :)

I think we should first decide on how and when to respond. Any feedback on this? I think for this we can not use tusd implementation as reference for this as it returns error 500 when sending more data than announced with Upload-Length.

[BlakeB415]

@Murderlon @Acconut Sorry for the delay. I'm still not sure when I'll be able to finish this. But don't lose hope :)

I think we should first decide on how and when to respond. Any feedback on this? I think for this we can not use tusd implementation as reference for this as it returns error 500 when sending more data than announced with Upload-Length.

For exceeding the max file size, 413 Request Entity Too Large is what the spec defines.

If the length of the upload exceeds the maximum, which MAY be specified using the Tus-Max-Size header, the Server MUST respond with the 413 Request Entity Too Large status.

https://tus.io/protocols/resumable-upload.html

[Acconut]

I think for this we can not use tusd implementation as reference for this as it returns error 500 when sending more data than announced with Upload-Length

This should not be the case, unless it's a bug. tusd is programmed to return a 413, just as @BlakeB415 mentions:

https://github.com/tus/tusd/blob/0e1169bdf182253d73c58bd118d6679cfb64b496/pkg/handler/unrouted_handler.go#L58
https://github.com/tus/tusd/blob/0e1169bdf182253d73c58bd118d6679cfb64b496/pkg/handler/unrouted_handler.go#L65

If you know more about when it returns a 500, let me know and I will try to fix it.

So +1 from me for 413.

[BlakeB415]

Can we pick this up again? This is a needed feature.

[Murderlon]

I can take this PR over. However I'm about to release 1.0.0 today or tomorrow and I don't have a date for you when I'll work on this yet. In the meantime the codebase has significantly changed as well, it's all TS while this is still in JS.

[fenos]

@Murderlon closing this, since has been implemented in #517