Acconut
commented
7 years ago first of all I would like to say congratulations to all guys helped to make the TUS protocol 1.0!
Thank you very much :)
client does not know the total size of the binary to upload
Just in case you forgot: The client must set the Upload-Defer-Length: 1 header to indicate this, so the server can recognize this scenario.
How to distinguish completed and uncompleted upload from server side?
An upload is completed if the length is known and the offset matches the length. In the other case, it's uncompleted.
Currently, my implementation would delete (expiration extension) the binary, as the Upload-Length Header was never ever set.
I would also recommend this approach :)
Is it in accordance to the spec that the client sends a very last "PATCH" with "Upload-Length" header but no content at all?
Yes, it is. The specification says that the Upload-Length must a "non-negative integer" which includes 0.
Hello everybody,
first of all I would like to say congratulations to all guys helped to make the TUS protocol 1.0! I am currently implementing the server part of the protocol and have troubles to understand the correct behaviour for the "creation-defer-length" extension.
My scenario is like:
1) client does not know the total size of the binary to upload 2) client does not set the Upload-Length during one of the next upload "patches" 3) client has completed the upload but did not send the "Upload-Length" with the last PATCH request.
How to distinguish completed and uncompleted upload from server side?
Currently, my implementation would delete (expiration extension) the binary, as the Upload-Length Header was never ever set. Is it in accordance to the spec that the client sends a very last "PATCH" with "Upload-Length" header but no content at all?
Greetings