Initial child-process side plumbing for starting an embedded ServiceWorker context

content/common/service_worker_messages.h

 // Copyright 2013 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.
 
 // Message definition file, included multiple times, hence no include guard.
 
 #include "base/strings/string16.h"
 #include "ipc/ipc_message_macros.h"
 #include "ipc/ipc_param_traits.h"
 #include "third_party/WebKit/public/platform/WebServiceWorkerError.h"
+#include "third_party/WebKit/public/web/WebContentSecurityPolicy.h"
 #include "url/gurl.h"
 
 #undef IPC_MESSAGE_EXPORT
 #define IPC_MESSAGE_EXPORT CONTENT_EXPORT
 
 #define IPC_MESSAGE_START ServiceWorkerMsgStart
 
 IPC_ENUM_TRAITS(blink::WebServiceWorkerError::ErrorType)
 
 // Messages sent from the child process to the browser.
@@ skipping 22 matching lines @@
                      int32 /* thread_id */,
                      int32 /* request_id */)
 
 // Sent when any kind of registration error occurs during a
 // RegisterServiceWorker / UnregisterServiceWorker handler above.
 IPC_MESSAGE_CONTROL4(ServiceWorkerMsg_ServiceWorkerRegistrationError,
                      int32 /* thread_id */,
                      int32 /* request_id */,
                      blink::WebServiceWorkerError::ErrorType /* code */,
                      string16 /* message */)
+
+// For EmbeddedWorker related messages -------------------------------------
+
+IPC_STRUCT_BEGIN(ServiceWorkerMsg_StartWorker_Params)
+  IPC_STRUCT_MEMBER(int32, embedded_worker_id)

[michaeln, 2013/11/19 01:17:08]

I have a question regarding int32 vs plain int? Our style guide says to prefer
plain 'int'. There are lots of <<>>_messages.h files that use plain 'int'.

Question is twofold...

Should we switch all of these messages to use plain int instead of int32 before
the 32 bit usages ripple far and wide?

Or has something changes such that we now prefer int32 in <<>>_message.h files? 
And if so, how do we prevent int32 types from rippling far and wide outside of
the message handlers?

[kinuko, 2013/11/19 07:45:42]

This sounds reasonable to me.
 
I don't think so, I basically blindly followed the convention in this file (and
also had a mindset that using specific int type in IPC is normal).

+  IPC_STRUCT_MEMBER(int64, service_worker_version_id)
+  IPC_STRUCT_MEMBER(GURL, script_url)
+  IPC_STRUCT_MEMBER(string16, content_security_policy)

[michaeln, 2013/11/19 01:17:08]

Where do these values come from and what do they mean? Is the CSP and TYPE
something that is delivered with the main script resource (in a particular
header for example)?

[kinuko, 2013/11/19 01:49:10]

That's what I'm trying to figure out now too..

As I wrote a question here:
https://codereview.chromium.org/70533005/diff/1/content/child/service_worker/...

Usually for shared / dedicated worker case we get the information from the
parent context's security context, but I'm not deadly sure yet how we should do
for service worker case (e.g. should we send it from provider host or if that's
something we could make up)

[kinuko, 2013/11/19 07:30:58]

Some more info:

It's for CSP, and the string's coming from Content-security-policy HTTP header.
I think we probably need to send this string from SWProvider.

Nice doc by Mike West:
http://www.html5rocks.com/en/tutorials/security/content-security-policy/

+  IPC_STRUCT_MEMBER(blink::WebContentSecurityPolicyType,
+                    content_security_policy_type)
+IPC_STRUCT_END()
+
+// Browser -> Renderer message to create a new embedded worker context.
+IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_StartWorker,
+                     ServiceWorkerMsg_StartWorker_Params)
+
+// Browser -> Renderer message to terminate the embedded worker.
+IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_TerminateWorker,
+                     int32 /* embedded_worker_id */)