Re: Draft v1 Update for Resumable Uploads

> On Jun 22, 2022, at 23:59, Greg Wilkins <gregw@webtide.com> wrote:
> 
> 
> Guoye et al,
> 
> I too agree with the sentiment that it would be good to avoid multipart with text boundaries.
> 
> I think the current draft would have each part being sent in a separate HTTP message.  I don't particularly mind that, but there are some latency concerns that the restriction on concurrent requests would introduce latency as you would need to wait for one part to be entirely complete before starting the next.
> 
> Eitherway, thinking about this made me realize that the current draft needs to discuss intermediaries and how they might handle the multiple requests in a resumed upload.     If a client is connected to a cluster with non-sticky bindings to back end servers, then a query for an offset or a resumed upload might end up on a different server within a cluster.
> 
> So either intermediaries need to be sticky on upload-token or other steps must be taken to ensure that a resumed conversation is sticky.

Yes, this has come up during our internal discussions. Currently, most applications have a global datastore that can be used to synchronize state, so any backend server the client talks to can still resume.

For use cases that can’t rely on global state such as within a load balancer, it is possible to use the upload token as a routing hint. Since the token is a random blob, we can hash it and use a deterministic algorithm to assign a destination.

Alternatively, the server can preemptively redirect so the upload targets a specific backend. However, redirection should be avoided if possible since it adds an extra roundtrip.

I’m a client-side implementor so I don’t have very much to add other than summarizing the previous discussions. Let me know if you think it’s worth adding a paragraph to the draft.

Guoye
> 
> cheers
> 
> 
> 
> 
> 
> 
> 
> On Thu, 23 Jun 2022 at 10:50, Guoye Zhang <guoye_zhang@apple.com <mailto:guoye_zhang@apple.com>> wrote:
>> 
>> 
>>> On Jun 20, 2022, at 03:00, Eric J Bowman <mellowmutt@zoho.com <mailto:mellowmutt@zoho.com>> wrote:
>>> 
>>> >
>>> > Maybe
>>> > https://www.ietf.org/archive/id/draft-ietf-httpbis-binary-message-05.html could 
>>> > be used; that would avoid the multipart parsing challenge.
>>> >
>>> 
>>> Ha, like I needed another hobby project from this thread! I get what you're saying, thx Julian. Section 3.8, Padding and Truncation -- message/bhttp as a general-purpose PATCH format for BLOBs.
>>> 
>>> -Eric
>>> 
>>> 
>> 
>> I’ll admit that I was confused by this exchange. I know binary message from oblivious HTTP, but I think Julian was suggesting replacing multipart part boundaries with binary message, not using it as the PATCH format. Let me explain what I understood from this discussion, please correct me if I’m wrong:
>> 
>> (1) My initial blocker for adopting Content-Range was that we needed a open range:
>> 
>>     :method: PATCH
>>     upload-offset: 42
>> 
>>     [Dynamically generated body with unknown length]
>> 
>> This is unrepresentable by Content-Range.
>> 
>> (2) Eric suggested multipart body with Content-Range, essentially:
>> 
>>     :method: PATCH
>>     content-type: multipart/sometime; boundary=“boundary"
>> 
>>     --boundary
>>     Content-Range: 42-50/*
>> 
>>     [8 bytes]
>>     --boundary
>>     Content-Range: 51-60/*
>> 
>>     [10 bytes]
>>     --boundary
>>     …
>> 
>> (3) I expressed concerns about multipart overhead.
>> 
>> (4) Julian suggested using binary message to serialize messages more efficiently, replacing plaintext headers and textual boundaries with the binary serialization format.
>> 
>> (5) Eric suggested using binary message itself as the PATCH format to represent arbitrary binary diff.
>> 
>> My reply to (4): If we need to invent a new format anyway, I’d avoid multipart since we don’t really need it for appending a continuous blob.
>> 
>> My reply to (5): I don’t think this is what binary message is for, but I’m really curious what you were able to achieve with this idea. Having a general-purpose binary patching format would be great.
>> 
>> Guoye
> 
> 
> -- 
> Greg Wilkins <gregw@webtide.com <mailto:gregw@webtide.com>> CTO http://webtide.com <http://webtide.com/>