Tested this issue on Windows-10 using chrome latest stable M55-55.0.2883.87 by following steps mentioned below.

1. Installed data saver extension to chrome
   https://chrome.google.com/webstore/detail/data-saver/pfmgfdlgomnbgkofeojodiodmgpgmkac?hl=en
2. Navigated to the below webpage
   http://gbf-wiki.com/attach2/696D67_333034303130353030305F30315F66756C6C2E706E67.png?random-text-here
3. Switched to dev console(Ctrl+Shift+I) and pasted the below command
   x = new XMLHttpRequest();
   x.open('GET', location.href);
   x.setRequestHeader('Accept', 'image/png');
   x.setRequestHeader('Cache-Control', 'no-transform');
   x.onload = function(){console.log(x.responseText.substr(0,4))};
   x.send();
4. Observed in console it print's saying "�PNG"

Reporter@ Could you please confirm is the above mentioned steps is the right way to reproduce this issue? If yes, I am unable to reproduce this issue.

Thanks!

Deleted: 679175.PNG 1.1 MB

	679175.PNG 1.1 MB View Download

You may need to replace the "random-text-here" at the end of the URL with a unique string of your choosing to avoid a cache hit at the proxy. The behavior of the proxy when there is an apparent cache hit has been unpredictable for me.

It's also important that "Disable cache" is turned off in the networking tab.

Here's a more automated test case:
http://www.4chan-x.net/test/datasaver/test.html

With
https://chrome.google.com/webstore/detail/data-saver/pfmgfdlgomnbgkofeojodiodmgpgmkac?hl=en
installed and the cache enabled, it displays "RIFF" instead of "�PNG".

With the cache disabled, there seems to be another bug, as it ignores the "Cache-Control: no-transform" request header (but not the lack of image/webp support in the Accept header), and is serving JPEG.

Able to reproduce this issue on Windows 10, Ubuntu 14.04 and mac 10.12.2 with chrome version #55.0.2883.87 and in canary version #57.0.2979.0

Observed that data saver is extension is compatible to chrome from M47 versions and from that version itself, the console output is displayed as RIFF, this is a non regression issue hence marking it has untriaged.
Attaching the screencast for your reference.

Deleted: Issue 679175-1.mp4 2.1 MB

	Issue 679175-1.mp4 2.1 MB View Download

I haven't read this thread in detail yet, however, let me point out briefly that the following statement is not entirely correct:

What is the expected behavior?
Either of these headers
 Accept: image/png
 Cache-Control: no-transform
should prevent conversion of the image to WebP,

Accept:image/png should prevent conversion to WebP, but Cache-Control:no-transform has no affect on the response. The meaning of CC:no-transform in the request is that the *request body* should not be transformed:
https://tools.ietf.org/html/rfc7234#section-5.2.1.6

Thanks for the report. I tried the examples manually. I can verify that given "Accept: image/png", Data Saver returns "Content-Type: image/png". Data Saver will not return "image/webp" unless Accept has "image/webp". Additionally, Data Saver adds "Vary: Accept" to tell the local cache that the response varies on the Accept header.

> Inspection of the headers reveals that the Data Saver proxy is
> forwarding the strong ETag validator from the server without
> modification, regardless of whether the image was sent from the
> proxy in PNG or WebP format. I believe this behavior is incorrect,
> and it may be the root of the problem.

This is a known issue and could definitely be the cause. Coincidentally, we just rolled out a fix for this issue a few days after you submitted your report. When I load that gbf-wikia image via Data Saver, I now get an ETag like the following:

etag: W/"CCP-ETag-R-ChAiNTg2NzgzMzctMjE2MWQiEh1TYXQsIDMxIERlYyAyMDE2IDEwOjA2OjQ3IEdNVBoA"

Given this change, I believe this bug has been fixed. admin@containerchan.org, can you verify?

Correction on comment #8: the fix is in the process of being rolled out and should be live globally within a day or so.

Ok, scratch that prior comment. It's been pointed out to me that the bug still exists and wasn't entirely fixed by the rollout. Thanks again for the report, we will try to complete the fix within a week or so.

This should be fixed by now. Please let us know if you run into any additional problems. Thanks!