Re: Working Group Last Call: draft-ietf-httpbis-resumable-upload-09

Hi Willy,

Thanks for your comment about the diagram. I see how this could be
confusing. In theory, a client might wait a short period for the arrival of
a 104 interim response to check the included Upload-Limit header and see if
data transfers have to be adjusted to fit the limits. That would be similar
to a client waiting on a 100 Continue response. However, I don't expect
generic clients to behave that way. Instead, I assume that most client
either start sending data optimistically without waiting on a 104. Or they
don't include any data in the initial upload creation request and use a
separate request to append data, for example because the client is not able
to receive interim responses.

I opened https://github.com/httpwg/http-extensions/issues/3263 to track how
we can improve the diagram and hopefully avoid this confusion for other
readers.

Best regards,
Marius

On Sun, Aug 24, 2025 at 6:57 AM Willy Tarreau <w@1wt.eu> wrote:

> Hi,
>
> Minor details from me, since Mike already reported a lot of things.
>
> I was initially confused by the first diagram in 3.1:
>
>    Client                                  Server
>    |                                            |
>    | POST /project/123/files                    |
>    | Upload-Complete: ?1                        |
>    |------------------------------------------->|
>    |                                            |
>    |                                            | Reserve resources
>    |                                            | for upload
>    |                                            |-----------------.
>    |                                            |                 |
>    |                                            |<----------------'
>    |                                            |
>    |            104 Upload Resumption Supported |
>    |            Location: /uploads/abc          |
>    |<-------------------------------------------|
>    |                                            |
>    X--------------Flow Interrupted--------------X
>
> Which I've read as:
>
> - client sends POST with headers
> - server returns 104
> - client the possibly uploads data
> - transfer is interrupted
>
> As an intermediary implemented it worried me that we'd have a new header
> that would cause uploads to wait for an interim response. When reading
> the rest I figured it does not make sense and is just my incorrect
> interpretation of the diagram. But it also means that others could
> possibly implement it like this (especially clients which could then
> wait for the 104 before sending data).
>
> I don't know how we could fix the diagram. Maybe adding an arrow from the
> client to the server in the middle, like this:
>
>    Client                                  Server
>    |                                            |
>    | POST /project/123/files                    |
>    | Upload-Complete: ?1                        |
>    |------------------------------------------->|
>    | body                                       |
>    |------------------------------------------->| Reserve resources
>    |                                            | for upload
>    |                                            |-----------------.
>    |                                            |                 |
>    |                                            |<----------------'
>    |                                            |
>    |            104 Upload Resumption Supported |
>    |            Location: /uploads/abc          |
>    |<-------------------------------------------|
>    |                                            |
>    X--------------Flow Interrupted--------------X
>
> At the moment that's about all from me (I've already added minor comments
> in a few issues about GET/HEAD and status codes, nothing that deserves
> discussing here).
>
> Regards,
> Willy
>
>