Ohh.. it could be this TODO:
TODO(falken): Support multipart byte range requests.

Or a bug in ServiceWorkerUtils::ExtractSinglePartHttpRange.

Or something about network service is putting bad values in the Range headers.

I'd trace where ExtractSinglePartHttpRange fails.

Thanks!

Just being digging into ExtractSinglePartHttpRange(). 
 Looks like we are hitting `byte_range.last_byte_position() < 0`.

https://cs.chromium.org/chromium/src/content/common/service_worker/service_worker_utils.cc?l=190&rcl=b167f41ce785881ea141c39ae1cdc39f5145edfc

GDB says |byte_range| is like:

$3 = (const net::HttpByteRange &) @0x2ef61ad0bc20: {
  first_byte_position_ = 0, 
  last_byte_position_ = -1, 
  suffix_length_ = -1, 
  has_computed_bounds_ = false
}

Hm, I suspect network service is using 0, -1 to mean "the entire range" and either that's not a valid range or ExtractSinglePartHttpRange needs to be taught about it.

Yeah, |input_range_header| is "bytes=0-". |last_byte_position| is -1 because it doesn't contain <range-end>. According to MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) it seems a valid Range header. Probably we should change the condition like:

bool res = ServiceWorkerUtils::ExtractSinglePartHttpRange(headers, &byte_range_set, &offset, &length);
if (!res && !byte_range_set) {
  return net::ERR_REQUEST_RANGE_NOT_SATISFIABLE;
}

?

Looks like we use BlobPtr::ReadAll for the entire range.
https://cs.chromium.org/chromium/src/content/common/service_worker/service_worker_loader_helpers.cc?l=152&rcl=e95188f16f1429d993b4146c82b8c596f402b762

cc dmurph for sanity checking about range headers and blobs.

Hm, I don't see where MDN says -1 means end of range, but the RFC has an example where -1 means the last byte.

I'm worried that we have to handle something like (40, -1) as well as (0,-1).

I guess the easiest thing for now could be to special case (0,-1), and have anything else return error.

I'd rather we keep the API that it returns false on invalid input only (see the function comment). So for (0,-1) we can return true with byte_range_set false, and (40, -1) we return false to indicate error, not supported.

Yeah, that sounds safer. The test passes when I change ServiceWorkerUtils::ExtractSinglePartHttpRange() returns true when there is only one range and it's (0, -1). Here, "pass" means the result is the same as non-S13nSW. There are still some FAILs in -expected.txt.

 Issue 807271  has been merged into this issue.

Uploaded a possible fix. I'll wait for dmurph@'s response.

https://chromium-review.googlesource.com/c/chromium/src/+/1013362

Thanks, feel free to send that out review and add me and dmurph (might be easier to notice than this bug)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b260357a806684da8226b75fd4d4d07a4e53a465

commit b260357a806684da8226b75fd4d4d07a4e53a465
Author: Kenichi Ishibashi <bashi@chromium.org>
Date: Tue Apr 17 04:48:49 2018

S13nSW: Treat the whole range is a valid range in ServiceWorkerUtils::ExtractSinglePartHttpRange()

This fixes S13nSW specific failures on
external/wpt/service-workers/service-worker/fetch-canvas-tainting-video-cache.https.html.
Note that "fix" here means that the result would be the same as
non-S13nSW. There are still some failures on the test page.

Bug:  833241 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I8c6dce03475cc50f0fb8900b73a8d7407606f170
Reviewed-on: https://chromium-review.googlesource.com/1013362
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551246}
[modify] https://crrev.com/b260357a806684da8226b75fd4d4d07a4e53a465/content/common/service_worker/service_worker_utils.cc
[modify] https://crrev.com/b260357a806684da8226b75fd4d4d07a4e53a465/third_party/WebKit/LayoutTests/FlagExpectations/enable-features=NetworkService