github.com/olivere/camlistore@v0.0.0-20140121221811-1b7ac2da0199/doc/protocol/blob-upload-resume.txt (about)

     1  Optional upload protocol extension:
     2  
     3  Blobs can be large, devices (e.g. mobile phones) can have slow
     4  uploads, or both.  Thus, it's nice to have an upload resume mechanism.
     5  
     6  In a stat response, a server can return a JSON key
     7  "alreadyHavePartially" with similar format to the spec-required "stat"
     8  array.  Instead of just "blobRef" and "size", though, there's a
     9  continuation key and blobref of the part that server already has:
    10  
    11  ...
    12     "alreadyHavePartially": [
    13        {"blobRef": "sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd",
    14         "size": 12312,
    15         "partBlobRef": "sha1-beefbeefbeefbeefbeefbeefbeefbeefbeefbeef"
    16         "resumeKey": "resume-sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd-12312-server-chosen",
    17         }
    18     ],
    19  ...
    20  
    21  If the client also supports this optional extension and parses the
    22  "alreadyHavePartially" section, the client may resume their upload by:
    23  
    24      1) verifying that digest of the client blob from byte 0 (incl) to
    25         "size" (exclusive) matches the server's provided "partBlobRef".
    26         (the server must use the same digest function).  if it doesn't,
    27         skip, and/or proceed to any other "alreadyHavePartially"
    28         blobref with the same "blobRef" value.  (the server may have
    29         multiple partial uploads in different states, and perhaps one
    30         is corrupt for various HTTP client failure reasons...)
    31  
    32      2) do an upload like normal, but the name of the
    33         multipart/form-data body part should be whatever the server
    34         provided in the mandatory "resumeKey" value.  skip the first
    35         "size" bytes in your upload.
    36