[ServiceWorker] Make Response class better conformance with the spec.

Source/modules/serviceworkers/ResponseInit.h

Index: Source/modules/serviceworkers/ResponseInit.h
diff --git a/Source/modules/serviceworkers/ResponseInit.h b/Source/modules/serviceworkers/ResponseInit.h
index bda31bd5aa5efa060d908307e065a9ca6b326fbe..01e00a7f35c94e1bc89f808782d045ba84f5583f 100644
--- a/Source/modules/serviceworkers/ResponseInit.h
+++ b/Source/modules/serviceworkers/ResponseInit.h
@@ -6,30 +6,34 @@
 #define ResponseInit_h
 
 #include "bindings/core/v8/Dictionary.h"
-#include "modules/serviceworkers/HeaderMap.h"
+#include "modules/serviceworkers/Headers.h"
 #include "wtf/RefPtr.h"
 
 namespace WebCore {
 
 struct ResponseInit {
     ResponseInit()
-        : status(200)
-        , statusText("OK")
+        : m_status(200)
+        , m_statusText("OK")
     {
     }
     explicit ResponseInit(const Dictionary& options)
-        : status(200)
-        , statusText("OK")
+        : m_status(200)
+        , m_statusText("OK")
     {
-        options.get("status", status);
+        options.get("status", m_status);
         // FIXME: Spec uses ByteString for statusText. http://crbug.com/347426
-        options.get("statusText", statusText);
-        options.get("headers", headers);
+        options.get("statusText", m_statusText);
+        options.get("headers", m_headers);
+        if (!m_headers) {
+            options.get("headers", m_headersDictionary);
+        }
     }
 
-    unsigned short status;
-    String statusText;
-    RefPtr<HeaderMap> headers;
+    unsigned short m_status;

[tkent, 2014/07/08 08:40:23]

We don't add m_ to struct members.

[falken, 2014/07/08 08:51:20]

I directed horo@ to add m_ after seeing jochen@'s comment on:
https://codereview.chromium.org/329853012/diff/330001/Source/modules/servicew...

Is there a definitive style decision?
(The codebase looks inconsistent about this, I see cases of both.)

[tkent, 2014/07/08 08:56:19]

http://www.chromium.org/blink/coding-style
The style guide says:
If an engineer thinks a struct is not a C++ class, he should not add "m_".
If an engineer thinks a struct is a kind of C++ class, he should make members
private. In this case, using struct makes no sense.

[horo, 2014/07/08 09:13:21]

Done.

+    String m_statusText;
+    RefPtr<Headers> m_headers;
+    Dictionary m_headersDictionary;
 };
 
 }