Cache API ignores Range header in match()
Reported by
alastair...@guardian.co.uk,
Aug 28 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8 Steps to reproduce the problem: 1. Cache a full response via the Cache API 2. Run cache.match() with a Request containing the Range header 3. Receive the full response in return What is the expected behavior? Ideally: receive a ranged response More immediately: throw an error. If you try to run cache.put() with a 206 partial response it returns "Partial response (status code 206) is unsupported", perhaps cache.match() should do something similar What went wrong? The Cache API doesn't seem to detect the Range header at all, so it's returning the response as if the header were not there. Did this work before? No Does this work in other browsers? No Firefox exhibits the same issue in the same way (other browsers don't have the Cache API) Chrome version: Version 60.0.3112.101 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Aug 28 2017
Spec issue is: https://github.com/w3c/ServiceWorker/issues/913
,
Aug 28 2017
Note that the SW folks decided "Browsers should fix themselves to work with 200 responses sensibly" which would indicate that the audio API should be fixed. Can you file an issue about the audio API getting 200 responses back for range requests?
,
Aug 29 2017
fwiw Chrome is pretty well optimised when it comes to blob.slice() here. You might find this code useful https://github.com/jakearchibald/range-request-test/blob/master/static/sw.js#L3
,
Aug 29 2017
Thanks for the feedback all - I will try to isolate a test for the audio tag issue and get back to you. It sounds like this issue is closed if this is intended behaviour. Jake - that's fantastic. I put together a solution using readable streams but I'll all the blob.slice() stuff in there to use when possible, sounds like it'll be much faster. https://github.com/gdnmobilelab/browser-range-response
,
Jan 18 2018
,
Mar 4 2018
Quick clarification - In effect, this means that partial 206 requests do not ever get cached locally, correct? That's the behavior I've been seeing across Chrome, Firefox, and Edge, even though the ETAG and range requests line up perfectly. Are there plans to change this behavior? I would think that caching partial requests would be very beneficial for all streaming video/audio applications. |
|||
►
Sign in to add a comment |
|||
Comment 1 by alastair...@guardian.co.uk
, Aug 28 2017