Add content_browsertests for testing cache control flags

Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng

Committed: https://crrev.com/e5aaf6a00745888f8fb79c8eec9b01d53f6436c7
Cr-Commit-Position: refs/heads/master@{#394356}

[Takashi Toyoshima, 2016-04-21 06:40:24]

Description was changed from

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheDqata flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

BUG=602900
==========

to

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheDqata flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
==========

[Takashi Toyoshima, 2016-04-21 06:48:06]

toyoshim@chromium.org changed reviewers:
+ hiroshige@chromium.org, japhet@chromium.org

[Takashi Toyoshima, 2016-04-21 06:54:18]

Hi, can you take a look? I may miss something, but I think this has been a
duplicated code for chrome.
I also confirmed that if I replace this with ("x-foo", "bar"), server receives
"cache-control: max-age=0" and "x-foo: bar" on reload.

Also this can remove two FetchContext::getCachePolicy() callers of four.

[Yoav Weiss, 2016-04-24 11:16:51]

On 2016/04/21 06:54:18, toyoshim wrote:
> Hi, can you take a look? I may miss something, but I think this has been a
> duplicated code for chrome.
> I also confirmed that if I replace this with ("x-foo", "bar"), server receives
> "cache-control: max-age=0" and "x-foo: bar" on reload.
> 
> Also this can remove two FetchContext::getCachePolicy() callers of four.

Does this result in no behavior change? i.e. Does Chrome continue to send
"max-age: 0" for revalidation requests even after this change?
If so, is that tested somewhere (presumably using browser tests)?

[Takashi Toyoshima, 2016-04-25 10:25:44]

> Does this result in no behavior change? i.e. Does Chrome continue to send
> "max-age: 0" for revalidation requests even after this change?

Yes, that's my understanding, and what my manual tests prove.

> If so, is that tested somewhere (presumably using browser tests)?

Let me check if there were tests for this. I'll try running all tests with a
change that ignores ValidatingCacheData flag.

[Takashi Toyoshima, 2016-04-25 10:26:04]

Description was changed from

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheDqata flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
==========

to

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
==========

[Takashi Toyoshima, 2016-04-26 04:25:57]

It seems we only have tests for reloading main resource or sub frame in layout
tests.
https://codereview.chromium.org/1913803002/

Since checking headers for sub resources isn't easy in layout tests, as you said
I need to write a browser test for this.

[Takashi Toyoshima, 2016-05-11 07:22:44]

Description was changed from

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
==========

to

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
TEST=content_browsertests
==========

[Takashi Toyoshima, 2016-05-11 09:31:16]

Description was changed from

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
TEST=content_browsertests
==========

to

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

[Takashi Toyoshima, 2016-05-11 09:32:21]

toyoshim@chromium.org changed reviewers:
+ phajdan.jr@chromium.org

[Takashi Toyoshima, 2016-05-11 09:32:46]

toyoshim@chromium.org changed reviewers:
+ kinuko@chromium.org

[Takashi Toyoshima, 2016-05-11 09:48:10]

+Paweł for test
+Kinuko for content

Yoav: Sorry for late, but I added some browser tests.

[kinuko, 2016-05-12 08:45:05]

the new test itself looks good, but it doesn't really look we're testing what we
change by this CL..?

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
File content/browser/loader/reload_cache_control_browsertest.cc (right):

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:41:
~ReloadCacheControlBrowserTest() override {}
nit: any reason we don't make this = default for this one too?

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:43: void SetUp()
override {
Could we do these in SetUpOnMainThread so that we don't need to call
ContentBrowserTest::SetUp explicitly?

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:51:
embedded_test_server()->Start();
ASSERT_TRUE(...)

https://codereview.chromium.org/1905873002/diff/60001/net/test/embedded_test_...
File net/test/embedded_test_server/embedded_test_server.h (right):

https://codereview.chromium.org/1905873002/diff/60001/net/test/embedded_test_...
net/test/embedded_test_server/embedded_test_server.h:212: // Adds request
monitor. The |callback| is called before any other handler is
nit: 'a request monitor' or 'request monitors'
'any other handler is' -> 'any handlers are'

https://codereview.chromium.org/1905873002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (left):

https://codereview.chromium.org/1905873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:549: if
(context().getCachePolicy() == CachePolicyRevalidate)
Hmm, it looks what we're changing here and the tests being added are not really
connected...

with the added tests I can see that calling
NavigationController::ReloadBypassingCache() sets cache control field but we
can't verify having CachePolicyRevalidate let the browser call
ReloadBypassingCache.

[Takashi Toyoshima, 2016-05-13 05:27:13]

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
File content/browser/loader/reload_cache_control_browsertest.cc (right):

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:41:
~ReloadCacheControlBrowserTest() override {}
On 2016/05/12 08:45:05, kinuko wrote:
> nit: any reason we don't make this = default for this one too?

Done.

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:43: void SetUp()
override {
Sounds better. Thanks.

https://codereview.chromium.org/1905873002/diff/60001/content/browser/loader/...
content/browser/loader/reload_cache_control_browsertest.cc:51:
embedded_test_server()->Start();
Thanks. Probably it's better to add WARN_UNUSED_RESULT in the test server
header? Let me try to add.

https://codereview.chromium.org/1905873002/diff/60001/net/test/embedded_test_...
File net/test/embedded_test_server/embedded_test_server.h (right):

https://codereview.chromium.org/1905873002/diff/60001/net/test/embedded_test_...
net/test/embedded_test_server/embedded_test_server.h:212: // Adds request
monitor. The |callback| is called before any other handler is
On 2016/05/12 08:45:05, kinuko wrote:
> nit: 'a request monitor' or 'request monitors'
> 'any other handler is' -> 'any handlers are'

Done.

https://codereview.chromium.org/1905873002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (left):

https://codereview.chromium.org/1905873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:549: if
(context().getCachePolicy() == CachePolicyRevalidate)
I conformed that this code path is used for the image reload in the NormalReload
test.

What I did:
 - Re-add this deleted code path, and change line 550 not to add Cache-Control
header, but add "x-foo: bar".
 - Check if x-foo" can be found in the browser tests
 - See the header on the second empty16x16.png load in the NormalReload test

[Takashi Toyoshima, 2016-05-13 05:47:08]

The CQ bit was checked by toyoshim@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-13 05:47:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/80001

[commit-bot: I haz the power, 2016-05-13 06:56:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-13 06:56:00]

Dry run: This issue passed the CQ dry run.

[Paweł Hajdan Jr., 2016-05-13 10:37:08]

LGTM w/nit

https://codereview.chromium.org/1905873002/diff/80001/net/test/embedded_test_...
File net/test/embedded_test_server/embedded_test_server.cc (right):

https://codereview.chromium.org/1905873002/diff/80001/net/test/embedded_test_...
net/test/embedded_test_server/embedded_test_server.cc:173: for (const auto&
handler : request_monitors_)
nit: Since we differentiate between handlers and monitors, the var should be
named |monitor|, not |handler|.

[kinuko, 2016-05-13 14:10:18]

Thanks for making sure the test code actually goes through the changes!

lgtm

https://codereview.chromium.org/1905873002/diff/80001/content/browser/service...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/1905873002/diff/80001/content/browser/service...
content/browser/service_worker/service_worker_browsertest.cc:1171:
ASSERT_TRUE(cross_origin_server.Start());
nit: this change looks fine but it's unrelated to this patch?

[kinuko, 2016-05-13 14:11:57]

https://codereview.chromium.org/1905873002/diff/80001/content/browser/service...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/1905873002/diff/80001/content/browser/service...
content/browser/service_worker/service_worker_browsertest.cc:1171:
ASSERT_TRUE(cross_origin_server.Start());
On 2016/05/13 14:10:18, kinuko wrote:
> nit: this change looks fine but it's unrelated to this patch?

I see, you needed this because you added the warning.  It'd be probably a bit
nicer to split the patch for the part then

[Takashi Toyoshima, 2016-05-16 04:08:57]

Changes related to WARN_UNUSED_RESULT was split to
https://codereview.chromium.org/1979173002/.
I will rebase this change with addressing nits of #19 once it is submitted.

Technically Paweł and Kinuko's reviews can cover all files, but I think it's
better to get reviewed by one memory cache specialist, Nate or Hiroshige?

[hiroshige, 2016-05-17 08:50:33]

ResourceRequest's http headers are observable in Blink (while the header added
in net// layer is not).
This can cause behavior changes, but as long as I briefly checked for Blink code
(search "Cache-Control" or "HTTPNames::Cache_Control" under
third_party/Webkit/Source/), there seems no such cases.
So the Blink code looks good.

I'm not sure about separation of cache-related logic in Chromium and Blink: this
CL makes Blink to set if-modified-since etc. but not to set cache-control.

https://codereview.chromium.org/1905873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/1905873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:546: const
AtomicString& eTag = resource->response().httpHeaderField(HTTPNames::ETag);
How about adding a comment that says "cache-control: max-age=0" header is added
in net// layer?

[Takashi Toyoshima, 2016-05-18 03:46:51]

Because the test is also useful for other changes that I'm currently working on
in parallel, let me submit the test that is already approved first, and do some
more investigation on the ResourceFetcher.

I'll invite related people to https://codereview.chromium.org/1987973002/ for
ResourceFetcher investigation.

[Takashi Toyoshima, 2016-05-18 03:56:27]

Description was changed from

==========
Reload cache control: remove redundant header insertion from Blink

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

This is historical code that exists before Chrome was born,
there WebKit does not assume our net like backend for networking.

This is one origin though it has moved around in tens of refactorings
https://chromium.googlesource.com/chromium/src/+/21a8f9925eacbc8016e44bb1bd81...

BUG=602900
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

to

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

[Takashi Toyoshima, 2016-05-18 03:56:37]

https://codereview.chromium.org/1905873002/diff/80001/net/test/embedded_test_...
File net/test/embedded_test_server/embedded_test_server.cc (right):

https://codereview.chromium.org/1905873002/diff/80001/net/test/embedded_test_...
net/test/embedded_test_server/embedded_test_server.cc:173: for (const auto&
handler : request_monitors_)
On 2016/05/13 10:37:08, Paweł Hajdan Jr. wrote:
> nit: Since we differentiate between handlers and monitors, the var should be
> named |monitor|, not |handler|.

Done.

[Takashi Toyoshima, 2016-05-18 03:56:49]

The CQ bit was checked by toyoshim@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-18 03:57:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/120001

[commit-bot: I haz the power, 2016-05-18 05:03:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-18 05:03:25]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Takashi Toyoshima, 2016-05-18 05:08:44]

Description was changed from

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases, and should not add such header for requests that
have other cache policies.

If request has ValidatingCacheData flag, net uses "max-age=0", too.

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

to

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

[Takashi Toyoshima, 2016-05-18 05:09:06]

The CQ bit was checked by toyoshim@chromium.org

[Takashi Toyoshima, 2016-05-18 05:09:07]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
phajdan.jr@chromium.org
Link to the patchset: https://codereview.chromium.org/1905873002/#ps120001
(title: "remove ResourceFetcher change temporarily, fix a nit of #19")

[commit-bot: I haz the power, 2016-05-18 05:09:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/120001

[commit-bot: I haz the power, 2016-05-18 06:00:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-18 06:00:22]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Takashi Toyoshima, 2016-05-18 06:12:57]

The CQ bit was checked by toyoshim@chromium.org

[commit-bot: I haz the power, 2016-05-18 06:13:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/120001

[commit-bot: I haz the power, 2016-05-18 06:39:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-18 06:39:17]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Takashi Toyoshima, 2016-05-18 06:55:40]

The CQ bit was checked by toyoshim@chromium.org

[commit-bot: I haz the power, 2016-05-18 06:55:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/120001

[commit-bot: I haz the power, 2016-05-18 07:55:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-18 07:55:07]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Takashi Toyoshima, 2016-05-18 08:03:29]

Description was changed from

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
==========

to

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng
==========

[Takashi Toyoshima, 2016-05-18 08:03:51]

The CQ bit was checked by toyoshim@chromium.org

[commit-bot: I haz the power, 2016-05-18 08:04:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1905873002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1905873002/120001

[commit-bot: I haz the power, 2016-05-18 08:08:02]

Description was changed from

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng
==========

to

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng
==========

[commit-bot: I haz the power, 2016-05-18 08:08:03]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-05-18 08:09:28]

Description was changed from

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng
==========

to

==========
Add content_browsertests for testing cache control flags

Now Blink inserts "Cache-Control: max-age=0" header for resource
revalidation. But we also use WebCachePolicy::ValidatingCacheData
in such cases so that //net uses "max-age=0".

So we can safely remove this insertion from Blink, and it would help
to avoid unexpected cache control flag mismatches.

Before making actual changes, submit some content_browsertests
that check cache control flags to avoid unexpected breakages.

These tests will be useful for other changes, e.g. pull-to-refresh
new behavior, and so on.

BUG=602900, 558829
TEST=content_browsertests --gtest_filter='ReloadCacheControlBrowserTest.*'
NOTRY=true # to skip unrelated failure on win_chromium_compile_dbg_ng

Committed: https://crrev.com/e5aaf6a00745888f8fb79c8eec9b01d53f6436c7
Cr-Commit-Position: refs/heads/master@{#394356}
==========

[commit-bot: I haz the power, 2016-05-18 08:09:29]

Patchset 7 (id:??) landed as
https://crrev.com/e5aaf6a00745888f8fb79c8eec9b01d53f6436c7
Cr-Commit-Position: refs/heads/master@{#394356}