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

content/common/service_worker_messages.h

Index: content/common/service_worker_messages.h
diff --git a/content/common/service_worker_messages.h b/content/common/service_worker_messages.h
index 92c6e908994ac442deec2399ce256e09ba4b638d..ab0e68c9e91143ecff377c9528e30c56d723d0ed 100644
--- a/content/common/service_worker_messages.h
+++ b/content/common/service_worker_messages.h
@@ -8,6 +8,7 @@
 #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
@@ -50,3 +51,22 @@ IPC_MESSAGE_CONTROL4(ServiceWorkerMsg_ServiceWorkerRegistrationError,
                      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 */)