[+gavinp, +jkarlin]  Hrm...Maybe some bug in HttpCache::Transaction when the client sets revalidation headers?

This is easy to repro, so don't think we need a net-internals log here.

FWIW, in Chrome 39, *if* the XHR is not async, I see the same behavior. 

Perhaps the regression is somehow related related to https://bugs.chromium.org/p/chromium/issues/detail?id=570622 ?

Good find!  That well could well be related.

[+japhet, +yoav]:  This issue sounds related to  issue 570622 , which you fixed in https://codereview.chromium.org/1558703002.

I think maybe I was mislead by similar symptoms but an unrelated root cause, because the CL in question only seems to have changed the behavior of Sync XHR and that isn't in use in this bug.

For this repro, no matter how many times I hit the GET Button, the Network Events log only contains one URL_REQUEST / DISK_CACHE_ENTRY pair for http://files.unity3d.com/alexsuvorov/bugs/chrome-revalidation/test.dat, until I hit the REVALIDATE Button, which creates its own URL_REQUEST/DISK_CACHE_ENTRY pair every time it is clicked. After that point, for the lifetime of the tab, every click on the GET Button creates another URL_REQUEST/DISK_CACHE_ENTRY pair. 

That suggests to me that there's a memory cache between the XHR and the network stack and it's servicing all of the plain XHR GET requests initially. Then the custom request with the cache-validation headers is made and its response (Warning: guessing here) evicts the original memory cache entry for the resource. At that point, all subsequent requests are deemed to require validation and the If-Modified-Since/ETAG pair is added to the network request which hits the DISK_CACHE entry.

NOT REPRO:
52.0.2733.0 dfad350a05c0affd2819a8e5b8025d50c7aa5508-refs/heads/master@{#393034}

REPRO:
52.0.2733.0 fe8a72da89b1941cccdd54a0da548540360286a6-refs/heads/master@{#393044}

In this range, the likely candidate seems to be https://codereview.chromium.org/1923003002 

elawrence:  Thanks for the bisect!  That CL does look a likely culprit.  CCing reviewers, and assigning to patch author.

[japhet]:  Since this wasn't noticed for all of M52, probably not urgent to fix it, but we should probably have a fix in M55, at least.

Marking R-B-S for M55 since a partner (Unity) discovered this and it's affecting their product.

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

commit d343f801f8cd63f985180bb4acb9cd4949e4c4b9
Author: japhet <japhet@chromium.org>
Date: Fri Sep 23 23:09:24 2016

Don't attempt to revalidate a Resource with a 304 response.

...which is counter-intuitive. Normally, a revalidation is started on a Resource
with a 2xx response. If the revalidation is successful (i.e, a 304 response),
Resource updates it's m_response with the headers that were received on the
304 response, but leaves the original 2xx response status code. A Resource with
a 304 status code on its m_response therefore received the 304 without thinking
it issued a revaldation. This could happen as a result of a server behaving
badly, or it could happen because an XHR was created with manually added
revalidation headers. In either case, the Resource is not guaranteed to have
sufficient information to perform a successful revalidtion, so don't attempt a
revalidation with it.

BUG= 643659 
TEST=ResourceTest.Revalidate304

Review-Url: https://codereview.chromium.org/2341893002
Cr-Commit-Position: refs/heads/master@{#420771}

[modify] https://crrev.com/d343f801f8cd63f985180bb4acb9cd4949e4c4b9/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/d343f801f8cd63f985180bb4acb9cd4949e4c4b9/third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp

Very nice. Thanks Nate for fixing this and adding a regression test.