Re: Byte range PATCH

> On Aug 3, 2022, at 14:39, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Thu, Aug 4, 2022, at 06:36, Austin William Wright wrote:
>> 3. It allows for some future extensions (if you omit the 
>> “Content-Range” field, you can use a different one to specify the 
>> target range).
> 
> When building for future extensions, consider whether you need a new extension point or whether an existing one is in fact better.  In this case, if you have no current need for extensions, that might continue, in which case you might be better off defining a new media type for your future use case.  See https://www.rfc-editor.org/rfc/rfc9170.html#name-version-negotiation and https://www.rfc-editor.org/rfc/rfc9170.html#name-fewer-extension-points (shameless self-promotion).


I agree, to the extent it's possible to extend the behavior, a new media type may still be ideal (it could be listed in Accept-Patch).

The fact that new behavior can be defined in the future is merely an observation: if there is no Content-Range field (or it's not well-formed), then the request is not meaningful.

In either case, there’s only one extension I can think of that would be meaningful: the ability to write an indefinite length at an offset. This would require a syntax like:

Content-Length: bytes 100-/*

… which is not currently well-formed (the "last-pos" is missing). However, maybe it should be. HTTP supports indefinite length responses (since HTTP/1.1), which can stream forever. Except this is not possible in partial content responses, and maybe it should be.

Thanks,

Austin.

Received on Wednesday, 3 August 2022 22:24:03 UTC