It is possible to control cache usage with DevTools. Namely there's a checkbox in DevTools network tab. Could you please check what's the state of the checkbox.

The disable cache checkbox is not selected (Nor is preserve log), throttling is disabled.  Should have mentioned this earlier, but I'm testing on Canary.  Stable seems to do the same thing, though.

Actually, I'll leave the label...Maybe it's relevant to your triage process, maybe not.

There might be something odd at play with Stale-While-Revalidate (given away by the SUPPORT_ASYNC_REVALIDATION)

Flag: chrome://flags/#enable-stale-while-revalidate)

Test cases: 
 1. Google Font CSS link (e.g. http://fonts.googleapis.com/css?family=Open+Sans)
 2. http://www.ggusd.us/ wait for 60s, devtools/reload/...


For #1, you might need to wait for the asset to go into the stale-while-revalidate period (i.e. wait for max-age = 1 day to pass).

For #2, the max-age window is very small (60 seconds).

I'll follow-up with the team.

Just realized that Google Fonts is always sending a 200 even for validations. So we should not read too much from that.

Can anyone reproduce with Canary and a non s-w-r asset?

Note that flag does not mean the assets are SWR assets - it just means if the asset supports SWR, to allow using it.  It's attached by the RDH at load start, and note when any caching flags are used.  https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/async_revalidation_manager.cc&sq=package:chromium&type=cs&l=166&rcl=1460690264

So that flag is a complete red herring.

mmenke@ which version did you use, or did you enable a special flag for DevTools?

I could not reproduce the first issue with trunk and stable with/without "Disable cache" of DevTools.

main resource: load_flags = 37122 (BYPASS_CACHE | MAIN_FRAME | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
sub resources: load_flags = 33026 (BYPASS_CACHE | MAYBE_USER_GESTURE | VERIFY_EV_CERT)

Per comment #3, I tested on Canary.

Oops, sorry you already said that disable cache checkbox wasn't set, and used canary.

Oh, this is interesting - I'm only seeing this for google search URLs, both https://www.google.com, and when there's a search query.

Right -- that was also my observation.

http://modpagespeed.com/images/Puzzle.jpg.pagespeed.ce.91_WewrLtP.jpg has these response headers:
  Accept-Ranges:bytes
  Cache-Control:max-age=31536000
  Connection:Keep-Alive
  Content-Length:241260
  Content-Type:image/jpeg
  Date:Sun, 10 Apr 2016 15:44:14 GMT
  Etag:W/"0"
  Expires:Mon, 10 Apr 2017 15:44:14 GMT
  Keep-Alive:timeout=5, max=99
  Last-Modified:Fri, 10 Jul 2015 19:19:44 GMT
  Link:<http://modpagespeed.com/images/Puzzle.jpg>; rel="canonical"
  Server:Apache/2.4.7 (Ubuntu)

https://www.google.com/images/nav_logo242_hr.png has these response headers:
  alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
  alternate-protocol:443:quic,p=1
  cache-control:private, max-age=31536000
  content-length:39373
  content-type:image/png
  date:Wed, 16 Mar 2016 16:47:20 GMT
  expires:Wed, 16 Mar 2016 16:47:20 GMT
  last-modified:Thu, 22 Oct 2015 17:33:49 GMT
  server:sffe
  status:200
  x-content-type-options:nosniff
  x-xss-protection:1; mode=block

One difference is that seems like it could be significant is that cache-extended pagespeed resources get an etag of W/"0", which was put in years ago to work around what we think was a bug in IE8.

Here are my observations, also with Chrome 49 on MacOS:

                            google.com image    mod_pagepseed.com image
return in URL bar           200 from cache      200 from cache
click on refresh button     200 from cache      304 (152 bytes)
shift-click on refresh      200 from cache      200 from network (236 kb)
control-click on refresh    200 from cache      200 from network (236 kb)
Command-R                   200 from cache      304 (152 bytes)

fyi, "disable cache" of DevTools changes the policy to BYPASS_CACHE here.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/inspector/InspectorResourceAgent.cpp&sq=package:chromium&type=cs&l=524

So, if someone changes it to VALIDATE_CACHE, it will be different code.

Hum... I'm not sure what was changed, but suddenly my chrome get to be able to reproduce the problem.

When I tried it at www.google.com, some resources are shown as "200 (from cache)", but all of them are using data URL. But, after I relaunched chrome, it was changed to show "200 (from cache)" for normal sub resources, and I could not see any data URL any more.

In my case, I could not see any new URL_REQUEST in chrome://net-internals/#events for the "200 (from cache)"s. I think this "cache" means blink memory cache because I saw multiple requests for nav_logo242.png in a breakpoint of ResourceFetcher, and the second and later requests use "Use" memory cache policy. But only one request appears at DevTool.

Some interesting facts that may help investigation:
 - Chrome does not apply reload related network options to resources that are requested after onload event fired.
 - preloaded resources seems to be shown as "from cache" even if the content is obtained from a server for the preload.

I just tried to reproduce this on canary and here are the flags I saw using chrome://net-export for url requests:

DevTools closed, clicked reload button:
  MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VALIDATE_CACHE
DevTools open, disable cache unchecked, clicked reload button:
  MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VALIDATE_CACHE
DevTools closed, shift clicked reload button:
  BYPASS_CACHE | MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE
DevTools open, disable cache unchecked, shift clicked reload button:
  BYPASS_CACHE | MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE

Subrequests (to favicon) also showed to have the same flags with and without DevTools open.

It would seem that DevTools is not changing the load flags anymore, so I am closing this. dgozman@ suggested this was fixed because of browser initiated requests. If anyone is able to reproduce this or find different results than mine, please comment/reopen.