Re: I-D Action: draft-ietf-httpbis-resumable-upload-06.txt

Dear working group,

we recently published a new version of our resumable upload draft. As
mentioned during the IETF 121 meeting, this iteration mostly consists of an
editorial overhaul, making the document easier to read and understand. In
particular, we restructured the document to have a dedicated section about
upload resources, which are the main entities facilitating resumable
uploads. In addition, the terminology usage has been improved and
unnecessary restrictions on HTTP messages have been removed, to better
align with the HTTP schematics laid out in RFC 9110. In particular, the
document now consistently talks about uploading *representations* instead
of vague *files*, making it a proper HTTP extension instead of just some
protocol that uses HTTP.

That being said, there were two minor normative changes:

- The "expires" limit, that controls the remaining lifetime, has been
renamed to "max-age" to better align with existing terminology.
- Responses for appending to upload no longer have to include the
Upload-Offset and Upload-Limit headers, which aren't needed by clients.
They now have to include the Upload-Complete header to distinguish whether
a response belongs to the upload process or the processing of the uploaded
representation. This is especially helpful for error cases.

One thing that has been brought up on the mailing list (and that I would
like to briefly discuss during the HTTP session in two weeks) has been the
use of PATCH requests for appending representation data. A client
continues/resumes an upload by appending representation data to the upload
resource (
https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-06.html#name-upload-append-2).
The current draft describes a PATCH request with the
application/partial-upload media type for this. In his recent review of the
draft (
https://mailarchive.ietf.org/arch/msg/httpbisa/m-iXTJQGdb8XpxGjZWxXGj6Siic/),
Roy Fielding (thank you for the thorough feedback!) argued that appending
representation data should be done through a POST request to the upload
resource. There was a brief discussion of the use of PATCH versus POST on
GitHub (https://github.com/httpwg/http-extensions/issues/2962), although I
don't sense a strong preference in any direction.

If I recall correctly, part of the motivation for PATCH might stem from a
time before the draft used upload resources. Back then an upload was
continued by sending a PATCH request with an Upload-Token header to the
same URI as the initial request did. Performing this with a POST request
could lead to issues if the server doesn't support resumable uploads,
similar to how a client cannot rely on the server supporting partial PUT. A
PATCH request with a custom media type prevents this issue since the server
explicitly has to accept the media type. However, nowadays the draft uses
upload resources that are explicitly created and announced by the server,
so in theory these compatibility concerns are no longer valid.

Thus I wanted to ask how the WG for any input. Should we stick with the
current PATCH + application/partial-upload or use POST instead?

You can find the current draft at
https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-06.html.
As always, we appreciate any form of feedback, whether it's about technical
details or unclear language.

We look forward to discussing this in the next meeting with you!

Best regards,
Marius

On Mon, Mar 3, 2025 at 11:54 PM <internet-drafts@ietf.org> wrote:

> Internet-Draft draft-ietf-httpbis-resumable-upload-06.txt is now
> available. It
> is a work item of the HTTP (HTTPBIS) WG of the IETF.
>
>    Title:   Resumable Uploads for HTTP
>    Authors: Marius Kleidl
>             Guoye Zhang
>             Lucas Pardue
>    Name:    draft-ietf-httpbis-resumable-upload-06.txt
>    Pages:   38
>    Dates:   2025-03-03
>
> Abstract:
>
>    HTTP clients often encounter interrupted data transfers as a result
>    of canceled requests or dropped connections.  Prior to interruption,
>    part of a representation may have been exchanged.  To complete the
>    transfer of the entire representation, it is often desirable to issue
>    subsequent requests that transfer only the remainder of the
>    representation.  HTTP range requests support this concept of
>    resumable downloads from server to client.  This document describes a
>    mechanism that supports resumable uploads from client to server using
>    HTTP.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-06.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-resumable-upload-06
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>