Re: [media-types] Feedback on a potential media type for upload chunks

[Mark Nottingham <[e-mail]>]

Yes, it's used by many APIs, etc.

Cheers,


> On 7 Mar 2024, at 03:55, Harald Alvestrand <[e-mail]> wrote:
> 
> 
> On 2/28/24 18:24, Mark Nottingham wrote:
>> PATCH _requires_ that the media type identifies the semantics of the body, so applciation/octet-stream is not suitable; it does not tell the receiving server what to do with those bytes.
>> 
>> See:
>>   https://www.rfc-editor.org/rfc/rfc5789.html#section-2
> 
> sigh ... I was hoping that application/octet-stream with range: would suffice for the simple case :-(
> 
> Is there any current deployment of PATCH in the wild?
> 
>> 
>> 
>> Cheers,
>> 
>> 
>>> On 28 Feb 2024, at 23:43, Harald Alvestrand <[e-mail]> wrote:
>>> 
>>> If the interpretation of a partial upload is simply a sequence of bytes, I would strongly suggest using application/octet-stream.
>>> 
>>> The semantics ("append this to the current upload") seem to be related to the request, not the media.
>>> 
>>> Some other considerations apply for files that are (for instance) uploaded in chunks, where each chunk is required to be semantically complete in some syntax (video frames for instance). In that case, registering a media type for "sequence of instances of type X that can usefully be concatenated with another sequence of instances of type X" - but this would strongly depend on exactly the file being transferred, not on the fact that this is done using a PATCH mechanism.
>>> 
>>> Hope this viewpoint is useful!
>>> 
>>> 
>>> On 2/26/24 20:01, Marius Kleidl wrote:
>>>> Dear working group,
>>>> in the HTTP working group, we are discussing a draft for resumable uploads over HTTP (https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/ <https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/>). Essentially, for each file that should be uploaded, a new upload resource is created on the server. The client can then append data to this upload resource by sending a PATCH request. If the transfer gets interrupted, the client can query the upload resource's current offset and then resume the upload by appending the remaining data using another PATCH request.
>>>> As required by RFC 5789, PATCH requests must include a media type to describe the message content. In the case of resumable uploads, the content is just a partial chunk from the file to be uploaded without any additional data included in the message content (no offset or length value). This chunk might be textual or binary depending on the file that should be uploaded (e.g. text file or video).
>>>> I didn't find a registered media type in the standards tree which matches those semantics. However, the vendor tree includes application/vnd.adobe.partial-upload (https://www.iana.org/assignments/media-types/application/vnd.adobe.partial-upload <https://www.iana.org/assignments/media-types/application/vnd.adobe.partial-upload>), which was registered by Adobe in 2009 for uploads in their web applications. Its intention seems to align with the content included in PATCH requests for resumable uploads.
>>>> Therefore, I am thinking about a standardized media type to describe partial chunks from an upload, such as application/partial-upload or application/upload-chunk and would love any feedback on that idea.
>>>> Best regards
>>>> Marius Kleidl
>>>> _______________________________________________
>>>> media-types mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/media-types
>>> _______________________________________________
>>> media-types mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/media-types
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

--
Mark Nottingham   https://www.mnot.net/