[
https://issues.apache.org/jira/browse/SLING-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559623#comment-13559623
]
Alexander Klimetschek commented on SLING-2707:
----------------------------------------------
I wonder if you couldn't do range uploads instead of chunks?
1) In case an upload fails (connection terminates, no 2xx response), the server
makes sure to save what he got so far (not sure if Sling does that already),
2) then the client does a HEAD on the file to see if it exists (partially) and
what it's current length is.
3) Now you do another PUT or PATCH (not sure what's "right" for range uploads)
with a Range that starts at the existing length.
Then there is no need to manage chunks on the server side, you only need to
append to an existing binary. Also it's all in the spec already AFAICS, no need
to invent a custom scheme.
AFAICS, this should also be possible in a (modern) browser, using Blob.slice()
from the html5 File API: http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice It
should also be possible to build it in a way that it falls back to re-uploading
everything in case the server does not allow range uploads.
Still some replies to the current design:
> Also: do we absolutely need the ".html" in the request URI?
Yes, the extension should really correspond to the response format. Note that
it could be different responses for the very same feature, one html, one json,
... (depending on the client).
I don't see any html here but json (on the "Query to retrieve last successful
chunk upload").
I would also put the chunk number in a selector instead of the somewhat long
"/chunk/<number>". For example, for the 2nd chunk:
POST /content/dam/dam-folder/asset.pdf.chunk.2.html
And avoid action verbs like "upload" in the URL... but as noted above, no
selector should be necessary at all.
> Support of chunked file upload into Sling
> -----------------------------------------
>
> Key: SLING-2707
> URL: https://issues.apache.org/jira/browse/SLING-2707
> Project: Sling
> Issue Type: New Feature
> Components: General
> Reporter: Shashank Gupta
> Attachments: uploadclient.jar
>
>
> Use cases:
> 1. Large file upload - With high speed internet connections, advent of cloud
> and HD going mainstream, Sling should support large files (> 2GB) upload.
> 2. Fault tolerant uploads - Sling should provide capability to resume upload
> from failure point. It should not require client to restart the complete
> upload process.
> 3. Faster upload: Sling should support its clients to initiate multiple
> connection and upload file chunks in parallel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
