httpwg
RESUMABLE: proposal to do different discovery mechanisms
@gstrauss provided the following feedback on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0094.html wrt Section 4.1.4
More broadly, I think that there could be many better ways to do "discovery" of the resumable-upload application rather than what is defined in the doc, and I hope more isolated, too. An independent request to create a temporary resource would be my starting point, maybe to a target under /.well-known/.
At this stage we need to see a more detailed proposal and support for adopting it.
Sample (not too detailed)
- Step 1: send request to create temporary resource via well-known URI.
- Step 2: send multiple requests to populate temporary resource. Partial-PUT is well-defined for modifying a file-based resource, in this case a temporary resource created in Step 1.
- Step 3: send request to submit temporary resource for processing. Once temporary resource is complete, define generic HTTP mechanism to ask server to use alternative URI for request body. I'll call this
Alt-Bodybelow.
Request:
GET /.well-known/temporary-resource HTTP/1.1
Destination: /target/processing
Response:
HTTP/1.1 201 Created
Location: /tmp/unique-hex-id-abcdef012345679
(Successful response indicates that server supports (made-up) Alt-Body for /target/processing URI.)
Request:
PUT /tmp/unique-hex-id-abcdef012345679 HTTP/1.1
...
(partial-PUT repeated in chunks, and let's assume for this sample that response is 204 for all partial-PUT requests)
Once client knows that temporary resource is complete: Request:
POST /target/processing HTTP/1.1
Alt-Body: /tmp/unique-hex-id-abcdef012345679
Alt-Body to indicate that server use the given URI instead of request body.
I should add that with happy-eye-balls, a request to the target resource with the request body could be made in parallel to a request for a temporary resource. If the original request succeeds, send a follow-up request to delete/abandon the temporary resource. If the original request fails due to disconnect, and the request can be safely repeated, start sending the request body to the temporary resource.
How is this proposal better than the current solution?
Infinitely.
- Much more robust. There is a separation of concerns between temporary resource creation and submission.
- Temporary resource population is under the full direction of the client and can be performed in parallel, in as many chunks as the client needs, and can be done using existing standards, i.e. partial PUT.
- There is room for extension to handle what resumable uploads does not handle, which is more robust transactional semantics or at least job queue submission and status retrieval. Right now, resumable uploads says confusingly that with
Upload-Complete: ?1, the upload resource belongs to the target URI.
This does not sound infinitely better to me. The client is asking the server to create state without any indication of the properties of the upload object.
There's no reason the request could not also include a structured field with parameters to more precisely communicate with the server the intended properties and use of the generic temporary resource. Similarly, headers besides Destination could be provided for the server to check policy before creating the temporary resource.
Regardless, the server policy should be rechecked at the point that the temporary resource is submitted to the target for processing.
I suggest writing a full design out to ensure that all aspects of your proposal are laid out and understood, such as by writing an Internet-Draft that can be read in whole and iterated on. Progressive design elaboration via comments is too hard for people to keep context on.
I might not have time to submit that until mid-Sept. I hope I have submitted enough actionable feedback that more discussion is warranted with the WG and last call on draft-ietf-httpbis-resumable-upload-09 can be extended.
Thats a decision for the chairs to make.
The authors plan to address the editorial and minor design issues that have been raised by mid-september.