Re: [httpapi] Byte range PATCH

[Darrel Miller <[e-mail]>]

Austin,

Thank you for sharing your proposal.  It is definitely the case that API providers do need this ability to perform partial updates to a resource.

However, it was my assumption that the updates to RFC 9110 that explicitly call out the potential for doing partial PUT https://www.rfc-editor.org/rfc/rfc9110.html#name-partial-put using the Content-Range header was the acknowledgement that this is what folks are doing and its ok to do it.

There are several assertions in your draft that suggest you don’t agree with this.

“this technique cannot generally be used in PUT, because the server may ignore the Content-Range header”

“However, if an upload is interrupted, no mechanism exists to upload only the remaining data; the entire request must be retried.”

“Although the Content-Range field cannot be used in the request headers without risking data corruption...”

In section 14.5 there is guidance that a server SHOULD respond with a 400 if Content-Range is received but not supported.  If this were a MUST, would that mitigate the concerns you raised?

Regarding your proposal, I do think there is value to being able to provide multiple parts to the content of the PATCH request.  I could imagine certain sync scenarios where that would be an efficient way of  communicating changes.

I’m not sure I understand the value of having a Content-Type as part of the header. I would have thought that patching would happen assuming the target is effectively application/octet-stream.  It would seem problematic to suggest doing a byte range update to a content-type that is text/plain when the charset is either not known or unspecified.  I don’t see how any kind of media type semantics would impact how the patch is performed.  I am only considering the case where range units are bytes.

My only other thought here is, are we reinventing things like VCDIFF https://www.rfc-editor.org/rfc/rfc3284 at this point?

Darrel


From: Austin William Wright<mailto:[e-mail]>
Sent: January 23, 2023 4:14 PM
To: HTTP APIs Working Group<mailto:[e-mail]>
Subject: [httpapi] Byte range PATCH

Hello HTTP APIs,

I’m seeking to standardize a media type for writing to particular byte offsets in a target document. This seems to be a common problem in HTTP applications, including in my own work with streaming parsers.

This sort of operation is common in filesystems. For example, you append audio data to a .wav file, and then you update the header at the start of the file. I don’t know of any way to do this operation over HTTP, except a PUT that replaces the entire resource.

This has been discussed in the HTTP WG list, as part of “resumable uploads”<https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html>, and I emailed there some months ago about this I-D. But aside from the resumable uploads being in HTTP WG, this seems more like an API-related feature.

Here’s the I-D I’ve written: draft-wright-http-patch-byterange-01<https://www.ietf.org/archive/id/draft-wright-http-patch-byterange-01.html>

Editor’s copy: https://awwright.github.io/http-progress/draft-wright-http-patch-byterange.html

This is the successor to version 00; in response to some feedback, I added a binary format. And I discuss what is necessary to support “splicing” (an insertion that shifts other content around) and indeterminate-length uploads, which is a requested feature for the “resumable uploads” spec.

Is HTTP APIs the best place to pursue this? I’m hoping I can discuss this at IETF 116.

Thanks,

Austin Wright.