draft-ietf-httpbis-resumable-upload-09: not ready: design

draft-ietf-httpbis-resumable-upload-09: not ready: design

Major Issues:
- It is an application; overly complex for a generic extension to HTTP
- It fails to discuss existing solutions
- It unnecessarily over-specifies application implementation details

draft-ietf-httpbis-resumable-upload has been in development for over 3 years.
None of these are new criticisms, yet remain unaddressed.



In April of 2022, I and others gave *detailed* feedback in thread [1]
on how tus-v2 (the precursor to resumable uploads) is an application,
and an application which does not leverage existing HTTP mechanisms.

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0000.html

My posts in that thread from April - June 2022:
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0052.html
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0224.html
[4] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0235.html
[5] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0239.html
[6] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0240.html
[7] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0242.html
[8] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0245.html



Application-specific drafts are now out-of-scope for HTTPWG according to
the recent draft proposal to update to HTTPWG charter [9] which states:
"This Working Group is charged with maintaining and developing the core specifications for HTTP and generic extensions to it (i.e., those that are not specific to one application)."

[9] https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0005.html

As currently written, draft-ietf-httpbis-resumable-upload reads to me as
a specific application.



Regarding already-existing HTTP mechanisms, back in 2022 I wrote:

In [6] above, I wrote:
> I have provided some examples how resumable uploads might be implemented
> using current standards, and so I request that any new protocol justify
> why current mechanisms are insufficient and why the new protocol is
> substantially better (and hopefully without adding new security
> headaches).

draft-ietf-httpbis-resumable-upload does not sufficiently address this.

In [8] above, I wrote:
> More generally, I think it useful to separate uploading a large resource
> (which might be interrupted) from processing that resource.
> 
> If a resource is uploaded via partial-PUT to a temporary file,
> e.g. to a path assigned by initial upload request, then the resource
> can be extended via partial-PUT until complete.
> 
> Once resource is completely uploaded, an HTTP request can be made to
> an endpoint requesting that the target be processed.
> 
> This sequence of requests can be achieved today with existing standards.
> 
> This loosely couples multiple HTTP requests to achieve a stateful upload
> before processing, where both client and server know that the upload is
> complete or not, and know that processing did not occur until the upload
> was complete.
> 
> Pre-requisites to allowing uploads, quotas, managing total disk usage,
> temp file lifetimes, etc. can be site-specific or application-specific,
> or both.

In contrast, draft-ietf-httpbis-resumable-upload describes a fragile,
overly-convoluted sequence of steps where the application requires
application-level state to be maintained on the server.  Additionally,
appending to an upload resource requires that a server or intermediaries
not block (by policy) the PATCH method.  Cancelling a resumable upload
requires that a server or intermediaries not block (by policy) the
DELETE method.  This is not a generic extension to HTTP.

draft-ietf-httpbis-resumable-upload describes the implementation of a
specific application (or two, depending on the approach) imposing that
the server maintain additional application-level state about the upload
resource and requiring many different parts of the server to participate
in conveying the availability of this application and state of the
upload resource.  It suggests changes needed in numerous different code
paths for servers to support resumable uploads.



In 2022, I tried giving more directed feedback on various github issues
[10] [11], but my feedback was largely dismissed by the
resumable-upload authors.  They seemed intent on pre-optimizing
for fabricated scenarios without data on realistic use.

[10] https://github.com/httpwg/http-extensions/pull/2292
https://github.com/httpwg/http-extensions/pull/2292#issuecomment-1304748660
https://github.com/httpwg/http-extensions/pull/2292#issuecomment-1304869022
[11] https://github.com/httpwg/http-extensions/issues/2239
https://github.com/httpwg/http-extensions/issues/2239#issuecomment-1312697792



Practically speaking, the vast majority of HTTP requests do not contain
large request bodies.  For those which do, another large swath of
requests uploads are static files.  If a client has access to upload
files, such as documents or pictures, one existing mechanism is to
upload to a temporary file and to rename once the upload is complete.
draft-ietf-httpbis-resumable-upload does not provide a compelling
alternative to existing solutions for this scenario.  iCloud, GDrive,
OneDrive, DropBox, and many others have solutions for syncing files.



draft-ietf-httpbis-resumable-upload may have some underlying intentions
which may be better extracted to one or more simpler RFCs.

I can envision a much simpler RFC to define a Content-Accum header with
a token that can be used by multiple requests to modify state of a
temporary resource, e.g. via partial-PUT.  Once complete, the token may
be used to indicate to a server to process a request using the temporary
resource in lieu of a request body.

This might be useful for CDNs or regional endpoints to collect a
request body from a flaky client over multiple partial uploads,
and then to send the completed request for processing.

This might be useful to scanners which check content for intellectual
property, GDPR, or other policy validation.

The client should manage the state of the temporary resource, uploading
the resource in chunks.  If a chunk fails, resend the chunk, perhaps
trying with a smaller chunk size.  The server may apply policies to
avoid abuse, but the server is not required to manage or maintain state
besides creating and mapping a token to a temporary resource, and the
temporary resource.  A client managing the state of the temporary
resource may send parallel uploads over multiple paths, which is an
artificial and hard limitation explicitly not supported in
draft-ietf-httpbis-resumable-upload.



I will follow this email with another which give more direct feedback
on the contents of draft-ietf-httpbis-resumable-upload.

I do not expect the original authors of TUSv2 or Resumable Uploads
to respond to these criticisms.  This post instead is directed towards
those evaluating draft-ietf-httpbis-resumable-upload for Last Call.

To those reviewers, my non-binding vote is that the resumable-upload
application should not be published as an RFC from the HTTPWG.


Cheers, Glenn
lighttpd developer
(among other things, author of the current lighttpd mod_webdav)

Received on Sunday, 10 August 2025 00:13:07 UTC