To fix the cross-site post submission bug.

content/public/common/frame_navigate_params.h

Index: content/public/common/frame_navigate_params.h
diff --git a/content/public/common/frame_navigate_params.h b/content/public/common/frame_navigate_params.h
index f3f686c9211d7f18bf33ebdd4b8f1e79dfb2397d..07df799125e995c719cd4ba9282befa658fe6e96 100644
--- a/content/public/common/frame_navigate_params.h
+++ b/content/public/common/frame_navigate_params.h
@@ -7,6 +7,7 @@
 
 #include <string>
 #include <vector>
+#include <map>
 
 #include "content/common/content_export.h"
 #include "content/public/common/page_transition_types.h"
@@ -14,9 +15,22 @@
 #include "content/public/common/referrer.h"
 #include "googleurl/src/gurl.h"
 #include "net/base/host_port_pair.h"
+#include "webkit/glue/resource_request_body.h"
 
 namespace content {
 
+// ViewMsg_Request will store all the request info.
+// I believe we should have a new file for this struct.
+struct CONTENT_EXPORT ViewMsg_Request {
+  ViewMsg_Request();
+  ~ViewMsg_Request();
+
+  std::string method;
+  GURL url;
+  std::map<std::string, std::string> headers;
+  scoped_refptr<webkit_glue::ResourceRequestBody> request_body;

[michaeln, 2012/11/02 00:08:23]

Would these additional params make more sense as additional params of the
FrameNavigateParams struct?

[irobert, 2012/11/02 17:22:55]

I think the question is whether do we need to keep ViewMsg_Request struct
covering every data or reuse some existing members in other params-structs.
The reason why I design like this is because I think this design is much clear.
There are several bugs (post-submission, redirect-Chain) which is due to the
request body lost during process swap. By keeping all of the request information
in one sturct, I think it will benefit others when they need to pass request
info from old process to new process. I don't know my concern is correct or not,
and I also got your point which is also reasonable. Could you give me some
comments on it?
Thanks

On 2012/11/02 00:08:23, michaeln wrote:

[michaeln, 2012/11/02 22:50:02]

Can you point me to a bug about redirect chain being busted due to the upload
body data going missing?

The presence of duplicate data members actually made things less clear to me
when reading thru it. I was left wondering "well, which url are we navigating to
really" and "what if these values are different, what might that mean, is that a
possibility".

Your new struct really doesn't include all of the request information, there's
all that other stuff in those surrounding structs as well. I would not attempt
to build one-ring-to-binds-them-all and instead make focused small changes that
let you accomplish the new behavior very specifically. The header map is a good
example of this. Imo it'd be better to just extend structs/params to convey the
value that you actually need (the contentType) and not anticipate some other
uses involving additional headers that may or may not ever come to be. If/when
other header values need to be handled, a map can be added at that time, no need
to do it now.

On 2012/11/02 17:22:55, irobert wrote:

+};
+
 // Struct used by WebContentsObserver.
 struct CONTENT_EXPORT FrameNavigateParams {
   FrameNavigateParams();