[
https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455510#comment-15455510
]
Ian Boston commented on SLING-6027:
-----------------------------------
Looking at how other applications address this problem, most do not rely on
parameters but use headers instead. This avoids a reliance on parameter order.
Most use the standard HTTP Header Content-Range which is defined in RFC 2616
section 14.16 as:
"The Content-Range entity-header is sent with a partial entity-body to specify
where in the full entity-body the partial body should be applied."
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
The Google Drive API supports partial and resumable uploads using the
Content-Range header as documented at
https://developers.google.com/drive/v3/web/manage-uploads
The advantage this would have over the current implementation is each part of a
multipart upload would be a complete definition of the Part of the Entity body.
The current Sling Specific protocol is:
{code}
POST /content/dam/folder HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=
Transfer-Encoding: chunked
Content-Type: multipart/form-data; boundary=CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1 (java 1.5)
Host: localhost:4502
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Content-Disposition: form-data; name="catalog.pdf@Length"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
1000
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Content-Disposition: form-data; name="catalog.pdf@Offset"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
400
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Content-Disposition: form-data; name="catalog.pdf"; filename="catalog.pdf"
Content-Type: application/pdf
Content-Transfer-Encoding: binary
$binary-data
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe--
{code}
Following RFC 2616 14.16 results in 1 Part defining the upload with no reliance
on order.
{code}
POST /content/dam/folder HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=
Transfer-Encoding: chunked
Content-Type: multipart/form-data; boundary=CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1 (java 1.5)
Host: localhost:4502
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe
Content-Disposition: form-data; name="catalog.pdf"; filename="catalog.pdf"
Content-Type: application/pdf
Content-Range: 400-799/1000
Content-Transfer-Encoding: binary
$binary-data
--CbZDcL_DxJIVQqSG1WkYaIoLWqT3FGYCVe--
{code}
A Content-Length header could also be added to the Part indicating the length
of the Part although this is not absolutely necessary. Content-Range can follow
any valid specification of range and length supported by the RFC.
This appears to be the approach adopted by the Google Drive API (and other
APIs), although it uses http status codes and the Range header to indicate what
was received rather than an html body.
> Support existing Chunked upload functionality in streaming mode.
> ----------------------------------------------------------------
>
> Key: SLING-6027
> URL: https://issues.apache.org/jira/browse/SLING-6027
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: Servlets Post 2.3.12
> Reporter: Ian Boston
>
> The non streaming uploads support a partial upload protocol implemented in
> request parameters that is known in Sling terms as "Chunked" upload and
> documented at
> https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support
> (not to be confused with Chunked Transfer encoding or the use of Http Range
> headers).
> Sling Chunked uploading sends a sequence of POSTs containing multiple parts
> of a file upload. When all the parts are uploaded a final request is sent
> that causes all the parts to be merged into a single file in the JCR. From a
> streaming point of view, each part can be streamed with the streaming
> implementation supported by SLING-5948. Some additional code will be required
> to set the file name appropriately and the struture.
> However, when the upload is completed, Sling must merge all the parts. To
> maintain the streaming nature of the upload, this must be achieved without
> incurring any local IO, otherwise the benefits of a streamed upload are lost.
> I am not certain how to achieve the merge given the limitations of the JCR
> API other than by transferring all the body parts via the local JVM. That
> won't incur local Disk IO but will multiply the overall IO requirement by 3x.
> If JCR/Oak had the functionality to concatenate Binaries it could do this
> more efficiently depending on the DS implementation. If JCR/Oak exposed an
> Seekable OutputStream the Application could avoid needing to save uploads to
> the JCR as individual files. If JCR/Oak allowed an update to a binary to
> start at a known location, again this could be avoided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
