Re: Draft v1 Update for Resumable Uploads

> 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