httpwg
RESUMABLE: proposal - revisit partial upload vs. PATCH discussion
@gstrauss provided the following feedback on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0094.html wrt Section 4.4.1
"A client can continue the upload and append representation data by sending a PATCH request with the application/partial-upload media type ..." Why Content-Type: application/partial-upload ? Could instead use Range request header and a proper Content-Type (or application/octet-stream) since the PATCH request is a byte range, already defined by the RFC. With OPTIONS, could use Accept-Patch. See the RFC 5789 for PATCH.
See https://github.com/httpwg/http-extensions/issues/2962. Is there any new information to warrant revisting this?
Iff the WG reconsiders some of the design limitations and reduces complexity by eliminating requirements for serial upload and Upload-Offset, then yes, it may make sense to also revisit the PATCH discussion.
As I posted in a different issue, perhaps the hesitation to using partial-PUT is the lack of a standardized discovery mechanism that a server supports RFC9110 partial-PUT.
Anyway, as much as I like both simplicity and also WebDAV, PUT would have several shortcomings, such as the resource being visible even when the transfer was interrupted.
...and all intermediates, right?
maybe "and caching intermediates" which modify the PUT instead of forwarding with headers intact. For resumable uploads, these intermediaries have to handle PATCH. I do not know if intermediaries would have more trouble with one or the other.
Anyway, as much as I like both simplicity and also WebDAV, PUT would have several shortcomings, such as the resource being visible even when the transfer was interrupted.
I don't think that is necessarily true. In fact, the temporary resource (or upload resource) should NEVER be publicly visible via GET or other methods except possibly for the IP address which sent it. Even then, it would be safer to not allow the intermediate resource to be accessible by GET or for that matter any method other than HEAD and PUT/PATCH. ...I was going to send this to the WG mailing list when I had more time to write it up, but I'll mention it here, too: if the temporary resource is accessible to GET, then that is a Security Consideration and can be used to steal bandwidth by someone uploading a temporary resource and then publishing links on their third-party website pointing to the temporary resource. It might also be used to place malicious content on the site, bypassing Content-Security-Policy (CSP).
@reschke do you have experience with dumb proxies and how they might not handle partial PUT? I am guessing they might turn it into a regular PUT by stripping out Content-Range. If a server supporting my proposal detects a PUT instead of a partial PUT to a temporary resource, then maybe I could return 405 Method Not Allowed and the client supporting resumable uploads could fall back to using POST to send the same request (other than method) to the temporary resource.
A similar fallback could not as easily be applied to resumable uploads using PATCH if the intermediary rejected PATCH as an unsupported method.
https://github.com/httpwg/http-extensions/issues/2962 discussed use of POST instead of patch. The outcome was to pick one, either seems like it could have worked. Is there evidence to suggest that PATCH in general is problematic? If so revising the method to POST is an option but I'd like to understand if justifiable effort first.
With OPTIONS, could use Accept-Patch. See the RFC 5789 for PATCH.
Should be covered by https://github.com/httpwg/http-extensions/pull/3242.
