2.5.2 Uploading a Very Large File
In this scenario, the client application will upload a very large file that will require a chunked uploading processing.
The definition of a very large file is arbitrary; the 2 GB limit of the web server could be used as the parameter (any file larger than 2 GB would be considered a “very large file”).
However, experimentation with the upload protocol showed that 600 MB is a better limit both for the client and server memory utilization and for the overall performance of the protocol.
So, in this scenario, the client application will take 600 MB as the limit and split up a file that is larger than that in chunks of 600 MB and upload each chunk in a separate request.
A chunked upload is always comprised with at least two requests, the first being an “upload file first chunk” action and the second being an “upload file last chunk” and zero or more optional “upload file middle chunk” requests.
For instance, in case a very large file can be split up in two chunks of 600 MB or less, the “upload file middle chunk” request will not be necessary.
The exception is in the case of a upload with resume (which is explained in the next section), which uses the chunk upload protocol, but has no “upload file first chunk” action, since the first file chunk is “already” in the server.
![](../__attachments/2002681945/53.gif?inst-v=533adeab-defe-4d59-a386-ead535dbfa6e)
Considering the file in the screenshot (“XP SP2 IE8 Hard Disk.vhd”), which has 1.71 GB, the client application will split it up in 3 chunks: the first one will have 600 MB (first chunk request), the second one also 600 MB (middle chunk request) and the last one will have 571 MB (last chunk request).
Since it is an internal upload scenario, the app has connected to the server and been provided a Session ID (SessionID_NNN). Also, the ID of target folder in the server is already known (RootFolderID_NNN).
Here it is the sequence of the requests (and resulting responses) required for this chunked upload. Note that after the first chunk upload request, the form field FileID and ExpectedSizeBeforeAppendChunk become required fields for all subsequent upload requests.
FileID should contain the X-FIleID provided by the first request, while ExpectedSizeBeforeAppendChunk should contain the number of bytes already uploaded to the server.
Request 1
Form Fields | Example |
---|---|
Upload operation | Internal upload |
Upload action | Upload file first chunk |
InternalUpload_AppletUID | SessionID_NNN |
ImmediateParentFolderID | RootFolderID_NNN |
RootFolderID | RootFolderID_NNN |
DeletePartiallyUploadedFile | 0 |
File Fields | Example |
name | File1 |
filename | XP SP2 IE8 Hard Disk.vhd |
[first chunk – 600 MB] |
Response 1
X-FileSystemLogOpID | LogOpID_NNN |
X-FileID | FileID_NNN |
X-FolderID | RootFolderID_NNN |
Request 2
Form Fields | Example |
---|---|
Upload operation | Internal upload |
Upload action | Upload file middle chunk |
InternalUpload_AppletUID | SessionID_NNN |
FileID | FileID_NNN |
ImmediateParentFolderID | RootFolderID_NNN |
RootFolderID | RootFolderID_NNN |
FileSystemLogOpID | LogOpID_NNN |
FolderName | IRM Functional Spec Screen |
DeletePartiallyUploadedFile | 0 |
ExpectedSizeBeforeAppendChunk | 629,145,600 (600 MB) |
File Fields | Example |
name | File1 |
filename | XP SP2 IE8 Hard Disk.vhd |
[second chunk – 600 MB] |
Response 2
X-FileSystemLogOpID | LogOpID_NNN |
X-FileID | FileID_NNN |
X-FolderID | FolderID_NNN |
Request 3
Form Fields | Example |
---|---|
Upload operation | Internal upload |
Upload action | Upload file last chunk |
InternalUpload_AppletUID | SessionID_NNN |
FileID | FileID_NNN |
ImmediateParentFolderID | RootID_NNN |
RootFolderID | RootFolderID_NNN |
FileSystemLogOpID | LogOpID_NNN |
DeletePartiallyUploadedFile | 0 |
ExpectedSizeBeforeAppendChunk | 1,258,291,200 (1.2 GB) |
File Fields | Example |
name | File1 |
filename | XP SP2 IE8 Hard Disk.vhd |
[final chunk – 571 MB] |
Response 3
X-FileSystemLogOpID | LogOpID_NNN |
X-FileID | FileID_NNN |
X-FolderID | RootFolderID_NNN |