Atomic patches and network interruptions

[Marius Kleidl <[e-mail]>]

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