Thanks for the report.

First of all, could you say a bit more about how this actually gets hit? At net/ level at least we don't ever generate multiple ranges ourselves, and don't handle multipart/byteranges[1], but I am not immediately sure of what happens if something like XHR or Fetch try.


[1] That seems mostly OK because of:
"A server MUST NOT generate a multipart response to a request for a
 single range, since a client that does not request multiple parts
 might not support multipart responses."

... but then again, APIs that let one set headers...

(Grabbing a netlog as described in https://www.chromium.org/for-testers/providing-network-details might also be helpful)

Thanks for reviewing.

You're right that Chrome doesn't generate a multi-range request ever, and it looks like I might be in error to respond with multipart/byteranges based on the quote you posted.

I think Chrome does need to at least handle "Content-Range: 100-200/*" (section 4.2, middle of page 13). (Note that the RFC doesn't say what the client is supposed to do after receiving a response like that -- presumably it should issue another request with "Range: bytes=201-"?)

Specifically, I'm trying to serve a resumable ("Accept-Ranges: bytes") download for dynamically generated content (total Content-Length unknown). I'm confused whether or not RFC7233 allows this. The initial request uses "Transfer-Encoding: chunked", but the subsequent Range requests don't seem to support an equivalent chunked transfer (Content-Range requires a byte length one way or another). Using multipart/byteranges as shown in my OP was the closest possible solution I could identify. I might try to seek clarification with IETF.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ah, actually it looks like IETF is currently working on the scenario that I described, and I just need to be patient. https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-02 and being discussed on the ietf-http-wg list.

As for single request with variable length: yep, current limitation; one that's not trivial to fix, but not as big as supporting multipart would be, I think.

(Our range handling in general probably needs a refactor, but I haven't come up with anything constructive at this point).