Documentation

Resume broken uploads

(since 1.3)

The resume implicitly implemented after partitioned upload feature — on file retry uploader will start at partition next to last succesfully uploaded. Of course, this could not be called pure resume, but it is still useful.

Benefits of such approach:

Simplicity — no need to implement client-server negotiation about resume offset (because only server knows real transfer completion status).

Drawbacks:

Data transfer overhead could be up to partition length;
Resume is not possible after applet terminated (or reloaded).

So, it is recommended to keep partition length about 1M for optimal performance.

Cross session resume

(since 2.76)

This mechanism allows upload to be resumed after applet destroy. Obviously, this requires interaction with server, because only server knows aborted upload details (file name, length, received content length, etc.). Therefore applet issue generic HTTP multipart POST request to the server (as it does with file upload), but:

without file data,
without file id, partition index and partition count parameters,
with additional parameter "fileName" which value is local file name.

Server should respond with HTTP OK (200) code and arbitrary content. Applet will parse each line of content and check, if it starts with known token:

Token (line begin)	Value	Example
fileId:	File ID to set	fileId:1
partitionIndex:	Partition index to start upload from (0-based)	partitionIndex:2

The URL for resume check specified by UploaderConfig.resumeCheckUrl parameter, i.e. could be assigned using uc_resumeCheckUrl applet parameter — if it is not empty, applet will perform resume check for each file being uploaded.