Re: Byte range PATCH

[Julian Reschke <[e-mail]>]

Am 03.08.2022 um 22:36 schrieb Austin William Wright:
> ...
> Hi Julian,
>
> I don’t have terribly strong opinions about what the format is, but this is what I thought was obvious based on a few motivations:
>
> 1. It re-uses an existing parser (it’s an off-the-shelf HTTP-message but skipping the "start-line CRLF” beginning, and is trivially parsable with a state machine or regular expression [1]).
> ...

That parser might be *present* everywhere, but not accessible. For
instance, a Java servlet engine happily processes HTTP/1.1 messages, but
doesn't provide an API to use that parser directly.

> 2. It allows segments to express HTTP semantics; for example, creating a resource relies on attaching a Content-Type field. You might even attach a Digest field indicating the expected hash of the final resource.

That should be on the request itself, no?

> 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).
>
> Would a binary format be able to accomplish this? I know there’s been some work on a binary HTTP message framing but I’m not up-to-date on this.

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/>

> [1] The regular expression for matching the fields a message/byterange document in draft-wright-http-patch-byterange-00 is, excluding obs- productions, is exactly:
>
> /^([!\x23-'\x2a\x2b\x2d\x2e0-9A-Z\x5e-z\x7c~]+:[\t ]*(?:[!-~](?:[\t -~]+[!-~])?)*[\t ]*\r\n)*\r\n/

Consider me sceptic. But I would need to dig in deeper to actually
check. It would be bad to have a format that looks like HTTP/1.1 but
then actually is slightly different.

Best regards, Julian