mirror of https://github.com/perkeep/perkeep.git
38 lines
1.5 KiB
Plaintext
38 lines
1.5 KiB
Plaintext
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 preupload response, a server can return a JSON key
|
|
"alreadyHavePartially" with similar format to the spec-required
|
|
"alreadyHave" 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.
|
|
|