Implement the infrastructure of creating WorkerFetchContext in worker global scope.

third_party/WebKit/public/platform/WebWorkerFetchContext.h

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef WebWorkerFetchContext_h
+#define WebWorkerFetchContext_h
+
+namespace base {
+class SingleThreadTaskRunner;
+}  // namespace base
+
+namespace blink {
+
+class WebURLLoader;
+class WebURLRequest;
+
+// WebWorkerFetchContext is created on the main thread and passed to a worker

[kinuko, 2017/04/18 08:00:31]

It'd be nicer to note that this is a per-worker object

[kinuko, 2017/04/18 08:00:31]

nit: and -> ,

[horo, 2017/04/18 12:53:35]

Done.

[horo, 2017/04/18 12:53:35]

Done.

+// (dedicated, shared, service worker) and initialized on the worker thread by
+// InitializeOnWorkerThread(). It contains information about the resource
+// fetching context (ex: service worker provider id), and is used to create a
+// new WebURLLoader instance in the worker thread.
+class WebWorkerFetchContext {
+ public:
+  virtual ~WebWorkerFetchContext() {}
+
+  virtual void InitializeOnWorkerThread(base::SingleThreadTaskRunner*) = 0;
+
+  // Returns a new WebURLLoader instance which is associated with the worker
+  // thread.
+  virtual WebURLLoader* CreateURLLoader() = 0;
+
+  // Called when a request is about to be sent out to modify the request to
+  // handle the request correctly in the loading stack later. (Example: service
+  // worker)
+  virtual void WillSendRequest(WebURLRequest&) = 0;
+
+  // Whether the fetch context is controlled by a service worker.
+  virtual bool IsControlledByServiceWorker() const = 0;
+
+  // Set the information about the resource fetching context. Must be called on
+  // the main thread.

[kinuko, 2017/04/18 08:00:31]

Ok I see, I looked at the dependent patch.  Hmm... I have a mixed feeling now. 
It certainly feels that it might be cleaner to have a separate class at least
for all the setting part.  Maybe have an internal Settings class and have
Initialize(Settings) method?  What do you think?  (Sorry for the back and forth)

By the way:
Do they really need to be called on the main thread, or do they just need to be
called *before* InitializeOnWorkerThread is called?

Also reg: RenderFrameImpl::PropagateAuxiliaryFetchContext() (not included in
this CL)-- do we really need this?  Note that we now have
DocumentLoader::GetServiceWorkerNetworkProvider(), so I think we can fill the
info entirely within Blink?

[kinuko, 2017/04/18 08:00:32]

Who calls these?

[kinuko, 2017/04/18 08:35:37]

Or we could also revisit this later too when we start to have more fields. (And
now I understand more clearly how WorkerFetchContext's implemented)
 

[horo, 2017/04/18 12:53:35]

Acknowledged.

[horo, 2017/04/18 12:53:35]

We don't have the information on the worker thread.
So it must be set on the main thread.
We don't need to set the provider ID in
RenderFrameImpl::PropagateAuxiliaryFetchContext().

But we have to set the parent frame ID to pass WorkerTest.WorkerTlsClientAuth
test. The parent frame ID is not available within Blink. 

[horo, 2017/04/18 12:53:35]

This will be called in
DedicatedWorkerMessagingProxyProviderImpl::CreateWorkerMessagingProxy() and
WebSharedWorkerImpl::OnScriptLoaderFinished().

[kinuko, 2017/04/19 03:24:49]

That's the caller side's constraint, not this class's constraint.

[kinuko, 2017/04/19 03:50:49]

I see. CreateWorkerFetchContext might rather be on WebFrameClient then?

+  virtual void SetServiceWorkerProviderID(int id) {}
+  virtual void SetIsControlledByServiceWorker(bool flag) {}
+};
+
+}  // namespace blink
+
+#endif  // WebWorkerFetchContext_h