- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Aug 2022 12:27:34 +1000
- To: Martin Thomson <mt@lowentropy.net>
- Cc: ietf-http-wg@w3.org
Right. The straightforward way to do this is to define a new media type (e.g., "application/binary-byteranges"). The ambitious way to do this is to define a new top-level type that's parallel to multipart/* (e.g., "bin-multipart/*"). Given that they all share the same framing (IIRC), that may be not too technically ambitious, but discussion would likely need to pull in a wider group of people. In both cases, you'd need to have a way to negotiate for it. For lyteranges, my initial thought it might be best to overload Accept-Ranges just a little bit; e.g., Accept-Ranges: bin-bytes Cheers, > On 4 Aug 2022, at 8:47 am, Martin Thomson <mt@lowentropy.net> wrote: > > On Thu, Aug 4, 2022, at 08:23, Austin William Wright wrote: >> 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. > > That, I think, points to Julian's solution. Imagine that the content of the message is something like this: > > 1. (optionally) a declaration of the total length of the thing you are intending to update (not sure about this one, frankly; it might just be better to have a signal that says "this is the end of the resource" or even a flag for "the last byte of this message is the last byte of the resource") > > 2. one or more chunks of data each with: > > a. a starting offset (maybe relative to the end of the previous one, or a gap) > b. some number of bytes, with a length prefix > > Encoding that in a binary format is almost trivial. And far easier to process than what you have described. > -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 4 August 2022 02:27:51 UTC