You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
For resumable uploads, it is useful and possible to save the received content of interrupted POST and PATCH requests. For example, if the transmission failed after 50MB, the server can save these 50MB, allowing the client to resume for this offset. This is also safe as the resource is never in an invalid state and a client can use the HEAD method to retrieve the current upload state and then resume accordingly.
However, the requirement from RFC 5789 might make this behavior not standards conform for PATCH request because the resource must not apply partial patch document. This would reduce the usefulness of resumable uploads if data from interrupted PATCH requests has to be discard. Of course, it is possible to divide an upload into multiple PATCH requests, where each request has a content volume that can easily retransmitted. But this comes at the cost of more request and the associated overhead on the client- and server-side.
Is there anything we can do?
This topic was also brought up on the mailing list.
The text was updated successfully, but these errors were encountered:
RFC 5789, which defines the PATCH method, places this requirement:
For resumable uploads, it is useful and possible to save the received content of interrupted POST and PATCH requests. For example, if the transmission failed after 50MB, the server can save these 50MB, allowing the client to resume for this offset. This is also safe as the resource is never in an invalid state and a client can use the HEAD method to retrieve the current upload state and then resume accordingly.
However, the requirement from RFC 5789 might make this behavior not standards conform for PATCH request because the resource must not apply partial patch document. This would reduce the usefulness of resumable uploads if data from interrupted PATCH requests has to be discard. Of course, it is possible to divide an upload into multiple PATCH requests, where each request has a content volume that can easily retransmitted. But this comes at the cost of more request and the associated overhead on the client- and server-side.
Is there anything we can do?
This topic was also brought up on the mailing list.
The text was updated successfully, but these errors were encountered: