Resumable Uploads for HTTP

Resumable Uploads for HTTP fixes the oldest practical problem with PUT: if the connection drops at 90%, you start over. The draft lets a server tell the client, with an interim 104 response, that this upload is resumable and where its upload resource lives; the client can then ask for the current offset and send the rest. It is designed so that a client that knows nothing about it sees an ordinary upload, and a server that supports it can be used by any client that does.

• One request to start - The first POST or PUT is the upload itself, with Upload-Complete saying whether this is all of it. Nothing extra is needed when nothing goes wrong.
• 104 Upload Resumption Supported - An interim status carrying the Location of the upload resource, sent before the final response so the client learns where to resume even if the request dies.
• Offset retrieval and append - HEAD on the upload resource returns Upload-Offset; a PATCH with the next bytes continues from there. Upload-Length lets the server validate the whole.
• Successor to tus - The document explicitly replaces draft-tus-httpbis-resumable-uploads-protocol; the tus community project is where the design was proven before the IETF took it on.

Every file-transfer API of the last fifteen years grew its own version of this — Amazon S3 multipart, Google Drive’s 308 Resume Incomplete, Microsoft Graph upload sessions, OCI chunked blob uploads — and none of them interoperate. This draft is the first attempt at one answer at the HTTP layer, where a proxy, a gateway or a client library can implement it once. It is also the mechanism the Model Context Protocol Files Working Group named in October 2026 as its candidate for resumability, with the reservation that pinning a specification to an Internet-Draft is risky. The draft has been through thirteen revisions and three organizations; it is close to done, and worth building against now.