ResourceFetcher::requestPreload should set its requestContext

Source/core/fetch/ResourceFetcher.cpp

Index: Source/core/fetch/ResourceFetcher.cpp
diff --git a/Source/core/fetch/ResourceFetcher.cpp b/Source/core/fetch/ResourceFetcher.cpp
index 81f56c4d602211d12db00e585140c541e7124199..7199fe569dc66a0043ab320c5984b35a28a3083b 100644
--- a/Source/core/fetch/ResourceFetcher.cpp
+++ b/Source/core/fetch/ResourceFetcher.cpp
@@ -1253,6 +1253,8 @@ void ResourceFetcher::requestPreload(Resource::Type type, FetchRequest& request,
     // Loading images involves several special cases, so use dedicated fetch method instead.
     if (type == Resource::Image)
         resource = fetchImage(request);
+
+    request.mutableResourceRequest().setRequestContext(WebURLRequest::RequestContextPrefetch);

[tyoshino (SeeGerritForStatus), 2014/11/11 07:57:26]

This looked the "context" defined in the Fetch Standard or something corresponds
to it.
https://fetch.spec.whatwg.org/#concept-request-context-frame-type
The comment on the enum definition says so. But after some study, it's similar
but it's not (yet).

Introduced to WebKit on this revision. Was Chromium specific before that.
https://chromium.googlesource.com/chromium/blink/+/ea0fe8306fdc519755ec85027d...

mkwst@ has renamed it to "context" as they're similar concepts.
https://chromium.googlesource.com/chromium/blink/+/6741e56bdbab3c9acebfe3caa0...

If we're making them closer in the future, we should investigate if it's
appropriate use of RequestContextPrefetch.

The "prefetch" context defined in the Fetch Standard is used for a link element
when its rel attribute is set to "prefetch". Blink does use it for this purpose,
but there're some other code using this in Chromium.

Hmm, I'd recommend that you call determineRequestContext() as
ResourceFetcher::createResourceForLoading() does unless you're sure you need to
use RequestContextPreftch context here.

[Mike West, 2014/11/11 08:08:04]

I don't understand this comment? The `prefetch` context is part of Fetch, which
is why it's part of the RequestContext enum.
(Because that's what Fetch calls it :) ).
The `<link prefetch>` comment in Fetch is an example, not an exhaustive list of
the points in the platform where the `prefetch` context is appropriate.
The practical question is whether requests that go through this path should be
checked for Mixed Content violations or not. So far, we've allowed prefetch
requests. If we change our minds on that (to match the spec), then we'll need to
know that this is a prefetch request.

[tyoshino (SeeGerritForStatus), 2014/11/11 08:20:36]

I wrote "not yet" since you've renamed it in
https://chromium.googlesource.com/chromium/blink/+/6741e56bdbab3c9acebfe3caa0...
and said "it's the first step towards a higher fidelity implementation of
Fetch's semantics".

I compared the current definition of the enum and the list of contexts defined
in the Fetch spec again. Yeah, they're same now. Sorry, my bad.
Oh, ok.

[tyoshino (SeeGerritForStatus), 2014/11/11 08:24:41]

OK.

Regarding mixed content, just issuing a request over the network bypassing mixed
content check is bad. Right? Then, we should have it set to appropriate context
even for preload.

Regarding CSP, it's ok to issue a request over the network bypassing CSP is ok
(though waste of bandwidth) but it's not fine to deliver the result bypassing
CSP. Right?

[tyoshino (SeeGerritForStatus), 2014/11/11 08:30:44]

By "deliver", I mean having it evaluated, displayed, etc.

     if (!resource)
         resource = requestResource(type, request);
     if (!resource || (m_preloads && m_preloads->contains(resource.get())))