Re: Draft v1 Update for Resumable Uploads

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.

cheers







On Thu, 23 Jun 2022 at 10:50, Guoye Zhang <guoye_zhang@apple.com> wrote:

>
>
> On Jun 20, 2022, at 03:00, Eric J Bowman <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> CTO http://webtide.com