To fix the cross-site post submission bug.

content/public/common/frame_navigate_params.h

 // Copyright (c) 2012 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.
 
 #ifndef CONTENT_PUBLIC_COMMON_FRAME_NAVIGATE_PARAMS_H_
 #define CONTENT_PUBLIC_COMMON_FRAME_NAVIGATE_PARAMS_H_
 
 #include <string>
 #include <vector>
+#include <map>
 
 #include "content/common/content_export.h"
 #include "content/public/common/page_transition_types.h"
 #include "content/public/common/password_form.h"
 #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();
   ~FrameNavigateParams();
 
   // Page ID of this navigation. The renderer creates a new unique page ID
   // anytime a new session history entry is created. This means you'll get new
   // page IDs for user actions, and the old page IDs will be reloaded when
   // iframes are loaded automatically.
   int32 page_id;
@@ skipping 35 matching lines @@
   // Contents MIME type of main frame.
   std::string contents_mime_type;
 
   // Remote address of the socket which fetched this resource.
   net::HostPortPair socket_address;
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_COMMON_FRAME_NAVIGATE_PARAMS_H_