Introducing the WebServiceWorkerCache.

Source/modules/serviceworkers/Response.cpp

Index: Source/modules/serviceworkers/Response.cpp
diff --git a/Source/modules/serviceworkers/Response.cpp b/Source/modules/serviceworkers/Response.cpp
index 7da6020ebf2a32cb5f8e16ddab47b650cc4a3836..3fa899976a7cfe29b8d2b8f0679acc6673d4c0d2 100644
--- a/Source/modules/serviceworkers/Response.cpp
+++ b/Source/modules/serviceworkers/Response.cpp
@@ -6,12 +6,44 @@
 #include "Response.h"
 
 #include "bindings/core/v8/Dictionary.h"
+#include "bindings/core/v8/ExceptionState.h"
 #include "core/fileapi/Blob.h"
 #include "modules/serviceworkers/FetchBodyStream.h"
 #include "modules/serviceworkers/ResponseInit.h"
+#include "public/platform/WebServiceWorkerResponse.h"
 
 namespace blink {
 
+namespace {
+
+PassRefPtrWillBeRawPtr<FetchResponseData> createFetchResponseDataFromWebResponse(const WebServiceWorkerResponse& webResponse)
+{
+    RefPtrWillBeRawPtr<FetchResponseData> response;
+    if (webResponse.status() < 200 || webResponse.status() >= 300)
+        response = FetchResponseData::createNetworkErrorResponse();
+    else
+        response = FetchResponseData::create();
+
+    response->setURL(webResponse.url());
+    response->setStatus(webResponse.status());
+    response->setStatusMessage(webResponse.statusText());
+    return response;
+}
+
+PassRefPtrWillBeRawPtr<Headers> createHeadersFromWebResponse(const WebServiceWorkerResponse& webResponse)
+{
+    RefPtrWillBeRawPtr<Headers> headers = Headers::create();
+    TrackExceptionState exceptionState;

[dominicc (has gone to gerrit), 2014/08/11 01:40:41]

Why does this track exceptions? Seems rather voodoo. Where is JavaScript here?

[gavinp, 2014/08/13 23:25:23]

I have ABSOLUTELY NO IDEA. I was shocked that this function on headers requires
this argument. Horo-san, what do you say?

+    for (HashMap<String, String>::const_iterator i = webResponse.headers().begin(), end = webResponse.headers().end(); i != end; ++i) {
+        headers->append(i->key, i->value, exceptionState);
+        if (exceptionState.hadException())
+            return PassRefPtrWillBeRawPtr<Headers>();
+    }
+    return headers;
+}
+
+}
+
 DEFINE_EMPTY_DESTRUCTOR_WILL_BE_REMOVED(Response);
 
 PassRefPtrWillBeRawPtr<Response> Response::create(Blob* body, const Dictionary& responseInit, ExceptionState& exceptionState)
@@ -98,6 +130,11 @@ PassRefPtrWillBeRawPtr<Response> Response::create(PassRefPtrWillBeRawPtr<FetchRe
     return adoptRefWillBeNoop(new Response(response));
 }
 
+PassRefPtrWillBeRawPtr<Response> Response::create(const WebServiceWorkerResponse& webResponse)
+{
+    return adoptRefWillBeNoop(new Response(webResponse));
+}
+
 String Response::type() const
 {
     // "The type attribute's getter must return response's type."
@@ -177,6 +214,15 @@ Response::Response(PassRefPtrWillBeRawPtr<FetchResponseData> response)
     ScriptWrappable::init(this);
 }
 
+// FIXME: Handle response body data.

[dominicc (has gone to gerrit), 2014/08/11 01:40:41]

Where do things like opacity, etc. flow through?

[gavinp, 2014/08/13 23:25:23]

Initially that won't be handled; this CL tries to avoid widening the
abstractions on the interface up to Chrome more than necessary to implement the
API. We'll need to follow up and implement these.

There's similar issues around referrer policies and a few other things like
this.

Would it be so crazy to stop having service_worker_types.h for Response/Request,
and instead make our WebServiceWorkerFOO objects be POD enough that we can use
them in messages? All these needless conversions make me sad, and worse yet
questions like this about capabilities that have to do with all of these
different data types make me even more sad.

+Response::Response(const WebServiceWorkerResponse& webResponse)
+    : m_response(createFetchResponseDataFromWebResponse(webResponse))
+    , m_headers(createHeadersFromWebResponse(webResponse))
+{
+    m_headers->setGuard(Headers::ResponseGuard);
+    ScriptWrappable::init(this);
+}
+
 void Response::trace(Visitor* visitor)
 {
     visitor->trace(m_response);