- From: Marius Kleidl <marius@transloadit.com>
- Date: Mon, 26 Feb 2024 20:30:38 +0100
- To: HTTP <ietf-http-wg@w3.org>
- Message-ID: <CANY19NtcgJJhArwufG+bH0EDSy6cSw4hSaZn_J9AykJv_5pJVA@mail.gmail.com>
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. How does this play out when the resource is not able to receive the entire patch document? For example, the client wants to send a 100MB patch document, but the connection is lost after 50MB. Is the resource then still allowed to apply the 50MB, which is the entire patch document that it received (assuming that it could apply the partial patch and that it is not invalid)? Or must the resource not apply anything because it cannot apply the entire patch document that the client wanted to transmit? The context for my question is draft-ietf-httpbis-resumable-upload. There it would be beneficial if the resource can save the partial content even if the request was not fully finished due to network issues and thereby saving this partial content from being retransmitted again. If the resource must not use the partial content, the client has to send the data again. Is such behavior in line with RFC 5789? Or could this be allowed if the corresponding media types explicitly allows applying partial content? Best regards, Marius Kleidl
Received on Monday, 26 February 2024 19:30:54 UTC