[ 
https://issues.apache.org/jira/browse/SLING-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580669#comment-13580669
 ] 

Alexander Klimetschek commented on SLING-2707:
----------------------------------------------

> IMO, since no resource get created until endpoint receives last chunk so 200 
> OK

The assumption here is that the final file is the only "resource" here - but 
IMHO that is not the case. The protocol allows to address the chunk resource(s) 
while the final file is not finished yet, so from the point of HTTP those 
intermediary steps are indeed resources. So that would speak for 201 all the 
way...

@Julian: what do you think of a HTTP-level solution involving the existing 
Range headers for uploads as I proposed above? Would that be in line with the 
spec? I really don't like the arbitrary ".chunk.<idx>" URLs...
                
> 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

Reply via email to