Resume uploads on different executions

[IvanRF]

If I execute a resumable upload for a file, kill the process and then start it again, there is no way to get the "upload_id" for the first file in order to continue with the upload in a new process. This can be tested with the DriveSample class on GitHub samples.

The class MediaHttpUploader creates and maintains a currentRequest (uploadType=resumable&upload_id=...) during one execution of resumableUpload(GenericUrl). However, there is no way to obtain and maintain that information for future processes.

My intention is to upload backup files in the background. If the user closes my application, I should be able to continue with the upload when the user starts the application again.

Original post: Issue 4131. Similar question here.

[geoffgibbs]

I have a possible solution here #966

I have been using a version of this locally for some time.

[IvanRF]

@geoffgibbs I didn't see that before. I will include my thoughts on the PR.

[hb0]

As far as I understood, this means that it's not possible to "initiate" Resume an interrupted upload as described in the protocol, but just if an existing connection is interrupted?

The client always expects the initial response to return 200/201. The protocol expects the response of the empty PUT request to be 308.

In which case do we need to setInitiationRequestMethod() to PUT then? After reading the protocol I thought this method allows us to request the Content-Range which would allow the MediaHttpUploader to slice the mediaContent accordingly and resume the upload there.