Re: [whatwg/fetch] blob: URLs and range requests (#1070)

Does anyone have any strong opinions on the answer for multiple ranges? I'm somewhat inclined to side with Chromium given that's how we normally guard things that we might support in the future, but WebKit's approach is reasonable too.

For the specification side of things we'll need to:

1. Split out the guts of https://fetch.spec.whatwg.org/#simple-range-header-value into a simple Range header parser (perhaps "extract a simple range"?). (If we could find a better word than "simple" that would be great.)
   1. Note that this parser needs to take a header list for consistency with "extract a MIME type" and friends. That also makes it clear that if you have multiple `Range` headers what value ends up being operated on and why that ends up failing (the comma).
   1. We should also test the various edge cases of this parser, including multiple `Range` headers and such.
1. Invoke that parser in scheme fetch and use the return values to slice the blob.
   1. Unfortunately https://w3c.github.io/FileAPI/#slice-method-algo doesn't call into an internal algorithm. This is a general problem with the File API specification. We can either use some language ~"act as if you're using the original unmodified version of this method" or fix it upstream.
1. We'll then read the sliced blob the same way we read the blob now. And we also need to setup the 206 response, presumably including a `Content-Range` header. (Tests also need to assert all aspects of this.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1070#issuecomment-1141315124
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1070/1141315124@github.com>