Resent-Date: Thu, 25 Jul 2024 11:15:16 +0000
Resent-Message-Id: <E1sWwRI-006otx-38@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) client-ip=2607:f8b0:4864:20::1029; envelope-from=toomim@gmail.com; helo=mail-pj1-x1029.google.com;
Content-Type: multipart/alternative;
 boundary="------------mLXPeq8Bku0ZeU4BXZOvcPpv"
Message-ID: <efb367a4-2abe-4daa-b94c-f0a62a3415ae@gmail.com>
Date: Thu, 25 Jul 2024 04:15:08 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Marius Kleidl <marius@transloadit.com>
Cc: ietf-http-wg@w3.org
References: <CANY19Ns76du=x04xtejdRrdNT2Lq_=5Huo5oH_KQ9qg5bAO89A@mail.gmail.com>
 <29911fc7-cfa3-4ea4-8ee0-822781060fa5@gmail.com>
 <CANY19Nt5XSjNguTY2poHvdLQF7p=TAEb1hX1p=ZS2siMCf-U0Q@mail.gmail.com>
Content-Language: en-US
From: Michael Toomim <toomim@gmail.com>
In-Reply-To: <CANY19Nt5XSjNguTY2poHvdLQF7p=TAEb1hX1p=ZS2siMCf-U0Q@mail.gmail.com>
Subject: Re: Resumable Upload draft updates
Archived-At: <https://www.w3.org/mid/efb367a4-2abe-4daa-b94c-f0a62a3415ae@gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

This is a multi-part message in MIME format.
--------------mLXPeq8Bku0ZeU4BXZOvcPpv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Marius, these are excellent questions! I am answering them inline below:

> 1. What is the parent version of a resource that a client is uploading 
> to? Requests have to set this header to ensure they are appending at 
> the correct offset, but I am wondering what parent version would be 
> included in responses to HEAD requests. The example responses in 
> section 3.3 always use the 0 byte count.

Ah, yes... Well, the parent header is actually redundant in that case— 
so I'm removing it from the example.

There, I think this 
<https://github.com/braid-org/braid-spec/commit/9e9485cdd4d2adcb0e7898b13919b06dc12ec496> 
is clearer now. How about you?

> 2. Can a client upload from a streaming data source without knowing 
> the entire file size upfront? Is the including of the Current-Version 
> header mandatory when starting an upload?

To best-support streaming resources of unknown length, we could 
articulate more into the Version-Type. For instance, we could define a 
special version ID called "end" that signals the end of a bytestream.

Then the initial request might look like this:

    PUT /something
    Current-Version: "end"
    Version-Type: bytestream
    Content-Length: 900

    <binary data of length 900>

Then the client could break up the file into multiple requests, e.g. by 
choosing a smaller number than 900 above, like you ask here:

> 4. Does the method allow the client to split an upload across multiple 
> requests? In our experience, servers can have an upper limit on the 
> size of a single request, which requires a client to split an upload 
> and send multiple consecutive requests to transfer the entire file.

Good question! I had to think on my feet to answer this one. :)

Finally, as for Content-Range:

> 3. The example request for case B in section 3.3.2 includes the 
> Content-Range header, which appears redundant. Does its value carry 
> additional information that is not covered by Parents, Current-Version 
> or Content-Length?
You're right that this is redundant information, but it might be useful 
for a Proxy that doesn't understand the bytestream version-type. It 
could still cache this range of the file! That's one of the cool things 
about re-using other headers and concepts. :)

These are such illustrative questions! It's really nice talking to other 
people who think about these things. :) Thanks for doing so!

Michael

--------------mLXPeq8Bku0ZeU4BXZOvcPpv
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Marius, these are excellent questions! I am answering them inline
      below:<br>
    </p>
    <blockquote type="cite"
cite="mid:CANY19Nt5XSjNguTY2poHvdLQF7p=TAEb1hX1p=ZS2siMCf-U0Q@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">1. What is the parent version of a resource that a
        client is uploading to? Requests have to set this header to
        ensure they are appending at the correct offset, but I am
        wondering what parent version would be included in responses to
        HEAD requests. The example responses in section 3.3 always use
        the 0 byte count.</div>
    </blockquote>
    <p>Ah, yes... Well, the parent header is actually redundant in that
      case— so I'm removing it from the example.</p>
    <p>There, I think <a
href="https://github.com/braid-org/braid-spec/commit/9e9485cdd4d2adcb0e7898b13919b06dc12ec496">this</a>
      is clearer now. How about you?<br>
    </p>
    <blockquote type="cite"
cite="mid:CANY19Nt5XSjNguTY2poHvdLQF7p=TAEb1hX1p=ZS2siMCf-U0Q@mail.gmail.com">
      <div dir="ltr">
        <div>2. Can a client upload from a streaming data source without
          knowing the entire file size upfront? Is the including of the
          Current-Version header mandatory when starting an upload?</div>
      </div>
    </blockquote>
    <p>To best-support streaming resources of unknown length, we could
      articulate more into the Version-Type. For instance, we could
      define a special version ID called "end" that signals the end of a
      bytestream.</p>
    <p>Then the initial request might look like this:<br>
    </p>
    <blockquote>
      <pre>PUT /something
Current-Version: "end"
Version-Type: bytestream
Content-Length: 900

&lt;binary data of length 900&gt;
</pre>
    </blockquote>
    <p>Then the client could break up the file into multiple requests,
      e.g. by choosing a smaller number than 900 above, like you ask
      here:<br>
    </p>
    <blockquote type="cite"
cite="mid:CANY19Nt5XSjNguTY2poHvdLQF7p=TAEb1hX1p=ZS2siMCf-U0Q@mail.gmail.com">
      <div dir="ltr">4. Does the method allow the client to split an
        upload across multiple requests? In our experience, servers can
        have an upper limit on the size of a single request, which
        requires a client to split an upload and send multiple
        consecutive requests to transfer the entire file.<br>
      </div>
    </blockquote>
    <p>Good question! I had to think on my feet to answer this one. :)</p>
    <p>Finally, as for Content-Range:</p>
    <p>
      <blockquote type="cite">
        <div>3. The example request for case B in section 3.3.2 includes
          the Content-Range header, which appears redundant. Does its
          value carry additional information that is not covered by
          Parents, Current-Version or Content-Length?</div>
      </blockquote>
      You're right that this is redundant information, but it might be
      useful for a Proxy that doesn't understand the bytestream
      version-type. It could still cache this range of the file! That's
      one of the cool things about re-using other headers and concepts.
      :)</p>
    <p>These are such illustrative questions! It's really nice talking
      to other people who think about these things. :) Thanks for doing
      so!</p>
    <p>Michael<br>
    </p>
  </body>
</html>

--------------mLXPeq8Bku0ZeU4BXZOvcPpv--