-
Notifications
You must be signed in to change notification settings - Fork 195
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
Add the Tus-Max-Size
extension
#310
Conversation
This PR is now ready to be worked on again. As for the approach, let's immediately respond with |
Tus-Max-Size
extension
@mitjap would you be willing to get this over the finish line soon? |
Any updates on this? May I also suggest a way to set this limit on a per-upload basis using hooks? |
@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 |
For exceeding the max file size,
|
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 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. |
Can we pick this up again? This is a needed feature. |
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. |
@Murderlon closing this, since has been implemented in #517 |
Closes #330
This PR is first step to support
Tus-Max-Size
extension. It limits amount of data uploaded to not exceedUpload-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 withheader
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: