Hi,

Would you mind providing a net log as described by these instructions?:

https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

It seems that the Range header in the request is only dropped in some specific cases. One requirement seems to be that the Content-Range response header does not contain the size of the file.

I also noticed that in some cases the net::ERR_CACHE_OPERATION_NOT_SUPPORTED error is shown. 

I encountered this bug when using the igv.js software. There is already some discussion about the bug in:

https://github.com/igvteam/igv.js/issues/424

As an attachment there is a net log which demonstrates dropped Range header. For demonstration purposes I used a dummy php script which always returns the same response independent of the request.

Deleted: chrome-net-export-log.json 1.3 MB

chrome-net-export-log.json 1.3 MB View Download

Thank you for providing more feedback. Adding requester "ckrasic@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If I go to phistuck-app.appspot.com and run the following -


function sendRangeRequest(url, start, end)
{
  var xhr = new XMLHttpRequest();

  xhr.open("Get", url);
  xhr.setRequestHeader("Range", "bytes=" + start + '-' + end);
  xhr.onload = function() { console.log("loaded " + url); }
  xhr.send();
}

var testUrl = "/blog/style.css";

for (var i = 0; i < 3; i++) {
  sendRangeRequest(testUrl, 0, 10);
}



Everything goes well.

Perhaps your server is not closing connections?

I don't think that not closing the connection is the problem. Shouldn't it cause problems when all ports (more then 10000) are used? This seems to occur earlier then that. Also, I'm using Apache locally with default configuration so everything should be OK.

It seems that this bug is quite difficult to replicate reliably. It is important to have a relatively large download (such as 1MB or more). When testing locally I also had to add some delay (1s) to demonstrate the bug.

You could try the following download (this file is used by the IGV browser I mentioned earlier): 

var testUrl = "https://s3.amazonaws.com/igv.broadinstitute.org/genomes/seq/hg19/hg19.fasta";

for (var i = 0; i < 3; i++) { sendRangeRequest(testUrl, 0, 1000000); }

At least for me, this gives in most cases (though not always) the error message net::ERR_CACHE_OPERATION_NOT_SUPPORTED. 

Replicating the dropping of Range header is even more difficult. Firstly, the reply should not have the Last-Modified header (to prevent cacheing). Secondly, the Content-Range header should not have the file size part.

As per comment #6 confirming this issue is not reproducible consistently, hence adding TE-NeedsTriageHelp for further updates. Could some one look in to this issue?

#6 - I still cannot reproduce. I tried running it multiple times (sorry for the bandwidth waste...) on this page (so this is a cross origin request) and on https://s3.amazonaws.com/igv.broadinstitute.org/genomes/seq/hg19/ (in order to make it a same-origin request).
I did get some HTTP 200 responses, but those were only in the former case, as responses to the OPTIONS requests (cross origin verification). The OPTIONS requests, expectedly, did not have a Range HTTP header.

(This is on Windows 7.)

If you can provide a net-log (you can stript personal information if it matters, it is a JSON file), as requested in #1, that could help.

I already provided a net-log in comment 3.

Oops! Sorry.

Well, it seems that WebTorrent users are also hitting this bug:

https://github.com/webtorrent/webtorrent/issues/1193

Perhaps this bug is only on Mac?

I think we are running to this issue on our application, and we can reproduce it very reliably only on mac. Here are the steps to reproduce:

1. Navigate to http://pdftron.com/webviewer/bugdemo/index2.html
2. Open developer tools and make sure "disable cache" is unchecked
3. Refresh the page 2+ times
4. You should see this error message: "GET http://pdftron.com/webviewer/bugdemo/PDF32000_2008.pdf net::ERR_CACHE_OPERATION_NOT_SUPPORTED"

This was not happening in previous chrome versions, and we can't reproduce it in any other browsers or on Windows.

re: comment #14: which version/channel is this report for? 
It's not with the incognito mode, right?

Also, what does chrome://net-internals/#httpCache say about Cache type?

(I suspect this may be at least partly a blockfile cache bug --- it and the memory backends are the things that issue ERR_CACHE_OPERATION_NOT_SUPPORTED --- 
neither the HttpCache::Transaction layer nor the simple backend do so --- 
... though it's very confusing why that wouldn't affect Windows)

It's not with the incognito mode, and my Chrome version is 61.0.3163.100 on the stable channel.

The cache type is "Blockfile Cache"

OK, can confirm on basis of testcase in #3 with content_shell --use-simple-cache-backend=off on Linux.

Not sure blockfile can do any sort of concurrent work on sparse stuff at all --- it doesn't seem to do any queing on background thread, and some sparse ops are a complex multi-step process...

 Issue 790686  has been merged into this issue.

Given  bug 790686  has been merged into this, can we get this out of Unconfirmed state, at the very least?

Wow, this is really annoying - I was hoping to use Range: requests to a .WARC file in a ServiceWorker to implement web archive replay. Serializing requests will result in pretty bad performance!