Chunking & Partitioning

With the advent of the File API, modern browsers now are capable of dividing files into “chunks” (also referred to as partitions). This feature is a crucial component to the resume feature, and makes the retry feature more useful. File chunking also provides a workaround for request size limits put in place by browsers (e.g., Firefox and Chrome limit upload request sizes to about 4GB).

Chunking is made possible by the File API, and is supported in Chrome, Firefox, Safari (iOS 6+ and OS X), Internet Explorer 10+, and Opera 15+. Chunking is disabled in Android’s stock browser due to a bug in the browser’s ability to upload Blobs.

Each chunk is sent in order and as a separate request, and each chunked request should be acknowledged much as you would for a non-chunked request because the response to each chunk-request is checked to determine success. If the server responds with a failure message, the uploader will attempt to retry sending the file starting with the last failed chunk if the autoRetry option is enabled.

The parameters on a chunked request will contain the following information:

{
    "qquuid": "380d6893-b98b-4189-9938-93d265dfab5d",
    "qqpartindex": 1,
    "qqpartbyteoffset": 2000000,
    "qqtotalfilesize": 15092995,
    "qqtotalparts": 8,
    "qqfilename": "NSA_PRISM.ppt",
    "qqchunksize": 2000000
}

The qqfilename parameter is only sent along with chunked requests that are multipart encoded. This is because multipart encoded uploads report the filename in the Content-Disposition header as “blob” or the empty string when a Blob is included in the request. So, to determine the original filename when dealing with a multipart encoded request, you must read the qqfilename property.

Custom parameters can be sent with each chunk. Those parameters can be set and modified in the chunking.paramNames option documented below.

Since each chunk comes in as a separate request, the server should save the chunk to a temporary location. The filename should be saved using the qquuid parameter to guarantee there are no collisions with other chunks. After all chunks have been received for a file (i.e., qqpartindex == qqtotalparts - 1) then you should combine all the chunks (in order) to recreate the original file.

Fine Uploader will also keep an eye out for a reset JSON property in the server’s response. When this property is present Fine Uploader will fail the upload and then restart the upload with the first chunk again on the next attempt (assuming auto or manual retry has been enabled).

For more information, see the associated blog post