Resumable Uploads: POST for appending data?

[Acconut]

In https://mailarchive.ietf.org/arch/msg/httpbisa/m-iXTJQGdb8XpxGjZWxXGj6Siic/, Roy Fielding suggests POST to be used instead of PATCH + application/octet-stream for appending data to an upload resource:

For example, use of the method PATCH for appending opaque data is incorrect. PATCH already has a defined semantic that could be used in parallel (e.g., another extension might use PATCH correctly). The resumable upload extension does not use a patch format, so both use of PATCH and creation of a new media type "application/partial-upload” are inappropriate.

POST should be used for appending data to the upload resource. This matches the semantics of POST and is easier to deploy in practice. Each POST can use “application/octet-stream” (or not send any Content-Type, since it has no role to play in processing).

Since we define the upload resource in the first place, we can also specify the meaning of a POST request against it and don't have to use PATCH with a custom media type to define the message's semantics.

Personally, I think both methods (POST or PATCH) are fine. What do others think about this?

[LPardue]

I'd rather not do both.

Avoiding creating a media type has the positive of saving some effort.

I tried to trace back the history of using PATCH in the first place and could not find a good answer. Does anyone have one?

[guoye-zhang]

I believe that @reschke suggested using PATCH and defining a new media type initially.

Personally I don't have a preference, either.

[reschke]

On 26.11.2024 04:48, Guoye Zhang wrote: I believe that @reschke suggested using PATCH and defining a new media type initially. Personally I don't have a preference, either.

I'm not sure I did, but yes, that seems to be the right thing to do. Best regards, Julian

[mnot]

Right, if we're going to use PATCH, the media type should describe how to handle the request content in a generic way. E.g., application/append-these-bytes.

That implies that it might be good to do so in a separate document, so it can be reused by other applications, rather than being perceived as specific to resumable uploads.

If that's thought of as too much work, POST is probably the right answer (with the semantics being defined by the specific resource type that's being baked into the resumable uploads spec).

But how could you resist creating a media type with a name like that?

[LPardue]

If its worth doing, it's worth doing right

[LPardue]

But also, didn't we have some of this discussion in the WG wrt https://datatracker.ietf.org/doc/draft-ietf-httpapi-patch-byterange/

[smatsson]

@LPardue We did. Both on the mailing list and on Github.

#2501 (byte range patch discussions)

https://mailarchive.ietf.org/arch/msg/httpbisa/UXTmMZaDNgtkMyA7broHeKL6vhg/ (contains discussions on POST vs PATCH)

https://mailarchive.ietf.org/arch/msg/httpbisa/aAfI1cZZDHnqhykFx4DoFClFocw/ (content type of PATCH and discussions if we can use it at all)

[Acconut]

Right, if we're going to use PATCH, the media type should describe how to handle the request content in a generic way. E.g., application/append-these-bytes.

That implies that it might be good to do so in a separate document, so it can be reused by other applications, rather than being perceived as specific to resumable uploads.

The current draft (-05) intents to define the application/partial-upload media type (https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-05.html#name-media-type-application-part) for use in PATCH requests when appending data, but this media type is specific to uploads and not very generic. We can consider renaming the media type and update its description to make it usable in other situations as well.

[mnot]

If it's spec-specific, that's good enough, I think.