- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Mon, 26 Feb 2024 16:41:01 -0500
- To: Marius Kleidl <marius@transloadit.com>
- Cc: HTTP <ietf-http-wg@w3.org>
On Mon, Feb 26, 2024 at 08:30:38PM +0100, Marius Kleidl wrote: > Dear working group, > > RFC 5789, which defines the PATCH method, places this requirement: > > The PATCH method requests that a set of changes described in the request > > entity be applied to the resource identified by the Request-URI. The set of > > changes is represented in a format called a "patch document" identified by > > a media type. > > [...] > > The server MUST apply the entire set of changes atomically and never > > provide (e.g., in response to a GET during this operation) a partially > > modified representation. If the entire patch document cannot be > > successfully applied, then the server MUST NOT apply any of the changes. This is very direct and very explicit. "atomically" means exactly that. > > If the entire patch document cannot be > > successfully applied, then the server MUST NOT apply any of the changes. The server MUST NOT apply an incomplete patch document. No exceptions. Among your options: The client can send smaller patch documents if changes are independent. (recommended) The server *application* handling the request could buffer and store the (partial) request body fragments, allowing for resumable uploads, and then apply the changes only once the entire patch document is received > Or could this be allowed if the > corresponding media types explicitly allows applying partial content? More questionable: a PATCH format might be defined/extended with a new media-type defining a format that consists of multiple patch documents which may be applied independently. The client would need some way(s) to query/validate which patch documents were applied. Again, per the RFC, each patch document must be applied atomically; never partially. Cheers, Glenn
Received on Tuesday, 27 February 2024 16:46:33 UTC