You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At IETF 115, Hans-Jörg Happel mentioned the idea of an extension to add checksum mechanism to resumable uploads.
One option is that the server calculates a checksum of completed uploads and provides it to the client, which can compare this checksum with an expected value. If the values do not match, the client can error out or retry the upload.
Another option is that the client tells the server the expected checksum in the beginning, and the server verifies the checksum once the upload is complete.
The text was updated successfully, but these errors were encountered:
HTTP digests can probably deal with both of these options. I would be resistant to implementing something new just for resumable uploads.
The question for me is how much, if at all, resumable uploads should discuss this kind of scenario. Maybe just mentioning the possibility of HTTP digeat, or maybe some examples if the sequence if messages is non-obvious. But we should try to keep text lean IMO.
Maybe just mentioning the possibility of HTTP digeat, or maybe some examples if the sequence if messages is non-obvious. But we should try to keep text lean IMO.
I agree. Such a mention and a few examples should be sufficient.
At IETF 115, Hans-Jörg Happel mentioned the idea of an extension to add checksum mechanism to resumable uploads.
One option is that the server calculates a checksum of completed uploads and provides it to the client, which can compare this checksum with an expected value. If the values do not match, the client can error out or retry the upload.
Another option is that the client tells the server the expected checksum in the beginning, and the server verifies the checksum once the upload is complete.
The text was updated successfully, but these errors were encountered: