Wasted bandwidth when proxying media

I'm not really sure if this should be a chrome issue, a fetch issue, or a service worker issue.

When a media element (video/audio) seeks to a different position, it fires off a new request for data from that position. So we get a new request for the same resource, but this time with a new Range header. In the service worker we need to grab this data from the cache or from the network, but both seem to cause resource contention when several requests come in at once.

If, for example, someone uses the seek scrubber on an audio element, 5-10 requests may be sent to the service worker in quick succession. Unfortunately, the service worker has no way of knowing that the audio element has abandoned all but the most recent request, so it dutifully sends responses for each of them.

If the requested content is in a cache, the worker sends back the cached response. This seems to cause a lot of data to be loaded into memory all at once (5-10 copies of the response body, which can be upwards of 50Mb for long podcast files or videos).

If the content is not available in the cache, then something even worse happens. 5-10 fetches are dispatched from within the service worker, which has no idea that most of those requests are no longer needed, and has no way to abort them even if it knew.

So the result of seeking though a piece of media served by a service worker is that, best case scenario, your browser slows to a crawl for a few seconds, and worst case scenario, you load 500Mb of uneeded data over a mobile internet connection.

Start by reviewing the service worker fetch handling and media Range-request behavior described in the issue. The payload names no files or tests, and the desired platform change is not defined; first establish whether obsolete requests can be identified or canceled, then define tests and acceptance criteria for seeking without redundant transfer or memory use.