Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resumable Upload: Saving content of interrupted PATCH requests #2760

Open
Acconut opened this issue Mar 16, 2024 · 0 comments
Open

Resumable Upload: Saving content of interrupted PATCH requests #2760

Acconut opened this issue Mar 16, 2024 · 0 comments

Comments

@Acconut
Copy link
Member

Acconut commented Mar 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant