mirror of https://github.com/perkeep/perkeep.git
39 lines
1.5 KiB
Markdown
39 lines
1.5 KiB
Markdown
|
# Blob Upload Resume
|
||
|
|
|
||
|
|
Optional upload protocol extension:
|
||
|
|
|
||
|
|
Blobs can be large, devices (e.g. mobile phones) can have slow
|
||
|
|
uploads, or both. Thus, it's nice to have an upload resume mechanism.
|
||
|
|
|
||
|
|
In a stat response, a server can return a JSON key
|
||
|
|
"alreadyHavePartially" with similar format to the spec-required "stat"
|
||
|
|
array. Instead of just "blobRef" and "size", though, there's a
|
||
|
|
continuation key and blobref of the part that server already has:
|
||
|
|
|
||
|
|
...
|
||
|
|
"alreadyHavePartially": [
|
||
|
|
{"blobRef": "sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd",
|
||
|
|
"size": 12312,
|
||
|
|
"partBlobRef": "sha1-beefbeefbeefbeefbeefbeefbeefbeefbeefbeef"
|
||
|
|
"resumeKey": "resume-sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd-12312-server-chosen",
|
||
|
|
}
|
||
|
|
],
|
||
|
|
...
|
||
|
|
|
||
|
|
If the client also supports this optional extension and parses the
|
||
|
|
"alreadyHavePartially" section, the client may resume their upload by:
|
||
|
|
|
||
|
|
1. verifying that digest of the client blob from byte 0 (incl) to
|
||
|
|
"size" (exclusive) matches the server's provided "partBlobRef".
|
||
|
|
(the server must use the same digest function). if it doesn't,
|
||
|
|
skip, and/or proceed to any other "alreadyHavePartially"
|
||
|
|
blobref with the same "blobRef" value. (the server may have
|
||
|
|
multiple partial uploads in different states, and perhaps one
|
||
|
|
is corrupt for various HTTP client failure reasons...)
|
||
|
|
|
||
|
|
2. do an upload like normal, but the name of the
|
||
|
|
multipart/form-data body part should be whatever the server
|
||
|
|
provided in the mandatory "resumeKey" value. skip the first
|
||
|
|
"size" bytes in your upload.
|
||
|
|
|