cache.match should create partial responses if given a range request

[jakearchibald]

I did some research on range requests, and everything's inconsistent https://docs.google.com/document/d/1SphP-WNxqzZrSv_6ApC9_FpM-m_tLzm57oL3SNGg-40/edit#heading=h.1k8r6xdc6vfo

The only reliable way of streaming video across browsers is for the server to return exactly the range requested. It feels like it's expected, and faster, for cache.match(request) to generate a 206 (or 416) if the request has a range header.

It'd be great to do this for opaque responses too, where the generated 206/416 would also be opaque, but I'd like a security person to weigh in there.

[wanderview]

What about on the put() side? If the server is providing partials, does cache have to stitch them back together for a cache.match() without a range header?

[jakearchibald]

I think we should reject putting 206s for now, but it's something we could look at in version n+1.

[ylafon]

ranged put should be avoided, patch would be far much better.

[jakearchibald]

@ylafon we're talking about the cache APIs put method, not the HTTP verb.

[ylafon]

Reading 'put' in the context of ranges triggers pavlovian reactions... Sorry for the noise.

[jakearchibald]

It'd be great to do this for opaque responses too

Hmm, I'm not sure this is a good idea. Imagine a file containing

blahblahblahblah('secret-data')blahblahblah

I could request bytes=0-31 and serve it in response to a <script src>, and get "secret-data".

[jakearchibald]

F2F:

• Browsers should fix themselves to work with 200 responses sensibly
• So making the change in this issue isn't urgent

[mkruisselbrink]

For what it's worth, it seems blink might start issuing range requests for tags in some situations at some point (https://groups.google.com/a/chromium.org/d/msg/blink-dev/pOTcSsMsAuo/YFiYRy7fAwAJ), but at least the design doc sounds like just replying with 200 responses to these requests should still work, so this shouldn't really change anything from the SW side of things I believe.

[inexorabletash]

Someone raised this on the Chromium bug tracker:

https://bugs.chromium.org/p/chromium/issues/detail?id=759630

[jakearchibald]

I've started some of the related work around this, eg whatwg/fetch#560 and whatwg/html#2814.

[mfalken]

F2F: Spec returning 206 from Cache Storage for range requests (likely making it a MAY to match http). Also, look into what sites are doing to see whether it would break things.

[wanderview]

FYI, Chrome has fixed https://crbug.com/847428 allowing range requests to pass through a service worker. We still block 206 responses in cache API, however. Does that change the priority of figuring this issue out?

By the way, if we do allow cache API to return 206 responses, I'd like to require that they be Accept-Encoding: Identity. This would allow browsers to compress non-identity responses on disk.