workbox-range-requests should be a passthrough when given a 206 response

[jeffposnick]

There's some movement to get the relevant specifications in place to have caches.match(), when passed a source Request containing a Range: header, automatically resolve with the correct partial HTTP 206 response.

That behavior is more or less what workbox-range-requests does already: it takes in a Request and Response pair, and returns a HTTP 206 Response with a body that reflects the Request's Range: (or a HTTP 416 if the response isn't long enough to satisfy the Range:).

The problem with the current workbox-range-requests behavior is that it assumes the source Response is always going to contain a complete Response body, not one that has already been sliced up. If it's passed a pre-sliced Response (due to browsers implementing changes to caches.match()), and then does it's own slicing, that's not going to lead to the proper response.

As a stop-gap, to prepare for a time when caches.match()'s behavior might change, I think a reasonable breaking change to workbox-range-requests's behavior, targeted for the v4 release, would be to first check the incoming Response object that it's passed, and if it already has a status of 206, just return it as-is. If it doesn't have a status of 206, then the existing logic will be applied.

I don't anticipate this affecting most current users today. Upgrading to workbox-range-requests v4 would be important if and when browsers start behaving differently, as using v3 would lead to double-slicing in updated browsers.

CC: @jakearchibald