To fix the cross-site post submission bug.

content/renderer/render_view_impl.cc

Index: content/renderer/render_view_impl.cc
diff --git a/content/renderer/render_view_impl.cc b/content/renderer/render_view_impl.cc
index 7d8db32089dc2643db70f074fbbef3646ae138ef..83e9c67c5a4ced7e490a1256c52789a50cc012fe 100644
--- a/content/renderer/render_view_impl.cc
+++ b/content/renderer/render_view_impl.cc
@@ -325,6 +325,7 @@ using content::DocumentState;
 using content::NavigationState;
 using content::PasswordForm;
 using content::Referrer;
+using content::WebHTTPPOSTBodyParams;
 using content::RenderThread;
 using content::RenderViewObserver;
 using content::RenderViewVisitor;
@@ -347,6 +348,16 @@ using WebKit::WebFloatRect;
 using WebKit::WebHitTestResult;
 #endif
 
+
+// Will find a proper place to move to.
+namespace content {
+  WebHTTPPOSTBodyParams::WebHTTPPOSTBodyParams() {
+  }
+
+  WebHTTPPOSTBodyParams::~WebHTTPPOSTBodyParams() {
+  }
+}
+
 //-----------------------------------------------------------------------------
 
 typedef std::map<WebKit::WebView*, RenderViewImpl*> ViewMap;
@@ -1215,22 +1226,39 @@ void RenderViewImpl::OnNavigate(const ViewMsg_Navigate_Params& params) {
       }
     }
 
-    if (params.is_post) {
-      request.setHTTPMethod(WebString::fromUTF8("POST"));
-
-      // Set post data.
+    // Deal With Cross-Process Post Submission
+    if(params.is_post) {
       WebHTTPBody http_body;
       http_body.initialize();
-      http_body.appendData(WebData(
-          reinterpret_cast<const char*>(
-              &params.browser_initiated_post_data.front()),
-          params.browser_initiated_post_data.size()));
+      std::vector<content::WebHTTPPOSTBodyParams> post_data = params.post_data;
+      for (std::vector<content::WebHTTPPOSTBodyParams>::iterator it=post_data.begin();
+           it < post_data.end(); it++) {
+        if ((*it).type == content::WebHTTPPOSTBodyParams::TypeData) {
+          std::string postdata = (*it).data;
+          http_body.appendData(WebData(postdata.c_str(), postdata.length()));
+        } else if ((*it).type == content::WebHTTPPOSTBodyParams::TypeFile) {
+          http_body.appendFileRange(WebString::fromUTF8((*it).filePath),
+                                    (*it).fileStart,
+                                    (*it).fileLength,
+                                    (*it).modificationTime);
+        } else if ((*it).type == content::WebHTTPPOSTBodyParams::TypeURL) {
+          http_body.appendURLRange((*it).url,
+                                   (*it).fileStart,
+                                   (*it).fileLength,
+                                   (*it).modificationTime);
+        } else if ((*it).type == content::WebHTTPPOSTBodyParams::TypeBlob) {
+        }
+      }
       request.setHTTPBody(http_body);
+      request.setHTTPMethod(WebString::fromUTF8("POST"));
+      WebString content_type_header = WebString::fromUTF8("Content-Type");
+      request.setHTTPHeaderField(
+          content_type_header,
+          WebString::fromUTF8(post_data[0].ContentType));      
     }
 
     main_frame->loadRequest(request);

[michaeln, 2012/10/24 23:45:39]

I see... this is where the new request is initiated... it does involve sending
the data to be posted to the destination renderer. If we had a WebHTTPBody
Element that meant "that browser initiated post data you already know about and
have sitting around in the browser process" we could avoid the extra round trip
of post data. As coded postdata flows like this...

- src renderer sends postdata to browser via the OnOpenPostURL.
- browser stores it in NavigationEntryImpl
- browser sends it to dst renderer via OnNavigate
- dst renderer sends it back to browser via WebRequest
- browser sends it over the network (hooray)

If the WebRequest could refer to the stored copy, we could cut out a round trip.

Also, this is where interpreting TypeURL (aka filesystem:// urls) could get
difficult. If the source and destination renderers use different storage
partitions, a filesystem://<origin>/<path> in one partition does not exist in
the other partition. Is it possible to cross-process post across storage
partition boundaries? If so, ResourceDispatcherHost will have to take that into
account when getting actual bytes to upload in the browser process.

And when does the stored copy of the postdata get cleared of the
NavigationEntryImpl?

[Charlie Reis, 2012/11/05 16:21:40]

Yeah, actually this concerns me.  Keeping the data in the browser process on
NavigationEntryImpl rather than trying to send it to the new renderer might be
worth some thought.

   }
-
   // In case LoadRequest failed before DidCreateDataSource was called.
   pending_navigation_params_.reset();
 }
@@ -1747,6 +1775,23 @@ void RenderViewImpl::OpenURL(WebFrame* frame,
       frame->identifier()));
 }
 
+// Do not sure whether to change the original OpenURL API by adding a new argument.
+// To avoid too much change, use OpenPostURL API do send ViewHostMsg_OpenPostURL
+// message to browser process.
+void RenderViewImpl::OpenPostURL(WebFrame* frame,
+                             const GURL& url,
+                             const Referrer& referrer,
+                             WebNavigationPolicy policy,
+                             std::vector<content::WebHTTPPOSTBodyParams> post_data) {
+  Send(new ViewHostMsg_OpenPostURL(
+      routing_id_,
+      url,
+      referrer,
+      NavigationPolicyToDisposition(policy),
+      frame->identifier(),
+      post_data));
+}
+
 // WebViewDelegate ------------------------------------------------------------
 
 void RenderViewImpl::LoadNavigationErrorPage(
@@ -2798,8 +2843,59 @@ WebNavigationPolicy RenderViewImpl::decidePolicyForNavigation(
     if (!net::RegistryControlledDomainService::SameDomainOrHost(frame_url,
                                                                 url) ||
         frame_url.scheme() != url.scheme()) {
-      OpenURL(frame, url, referrer, default_policy);
-      return WebKit::WebNavigationPolicyIgnore;
+      WebString method = request.httpMethod();
+      if(method != WebString("POST")) {
+        OpenURL(frame, url, referrer, default_policy);

[michaeln, 2012/10/23 23:22:18]

I see, so in navigations that get initiated in one renderer and satisfied in
another... we cancel the webcore navigation by returning
WebNavigationPolicyIgnore? Is this the only mechanism for process swapping
navigations where the navigation is initiated by webcore?

[Charlie Reis, 2012/10/24 00:40:37]

I haven't looked at the rest of this CL yet, but I saw this question and wanted
to chime in.  Yes, this is currently the only way that we punt a navigation to
the browser process from the renderer process.  (Eventually I'd like the browser
process to do the intercepting rather than relying on the somewhat-untrusted
renderer, but that's a different project.)

On 2012/10/23 23:22:18, michaeln wrote:

[michaeln, 2012/11/02 01:19:24]

It might be slick if post data delivered from rendererA was sent up more or less
as usual, but the response data was piped over to rendererB for parsing and
renderering. A resource load where the upload part happens for A and the
download part happens for B.

Looks like there's some logic in ResourceDispatcherHost for transferring a
deferred ResourceLoader from one process to another? Does this logic have
anything todo with cross-site'isms or is that about something else? Maybe
another potential place to stash the 'postData' could be a deferred
ResourceLoader that gets created by A and later picked up by B (purely a
creature of the IO thread) instead of the navigation entry (UI thread thingy).

void ResourceDispatcherHostImpl::BeginRequest(
    int request_id,
    const ResourceHostMsg_Request& request_data,
    IPC::Message* sync_result,  // only valid for sync
    int route_id) {
  .....
  // If the request that's coming in is being transferred from another process,
  // we want to reuse and resume the old loader rather than start a new one.
  linked_ptr<ResourceLoader> deferred_loader;
  {
    LoaderMap::iterator it = pending_loaders_.find(
        GlobalRequestID(request_data.transferred_request_child_id,
                        request_data.transferred_request_request_id));
    if (it != pending_loaders_.end()) {
      if (it->second->is_transferring()) {
        deferred_loader = it->second;
        pending_loaders_.erase(it);
      } else {
        RecordAction(UserMetricsAction("BadMessageTerminate_RDH"));
        filter_->BadMessageReceived();
        return;
      }
    }
  }

But as you say... this would be a differen project?

[Charlie Reis, 2012/11/05 16:21:40]

Matt Perry added that for doing a process swap during server redirects. 
Ultimately I'd like to switch all the RenderViewImpl::decidePolicyForNavigation
stuff to this approach, but I'm worried about the size of that project.  Perhaps
it's worth a chat with Matt for a sanity check, though.

+        return WebKit::WebNavigationPolicyIgnore;
+      }
+      else {
+        // Extract Body Info
+        WebHTTPBody body = request.httpBody();
+        std::vector<content::WebHTTPPOSTBodyParams> post_data;
+        WebKit::WebHTTPBody::Element element;
+        for (int i=0; body.elementAt(i, element); i++) {
+          content::WebHTTPPOSTBodyParams post_param;
+            post_param.method = "POST";
+          if (element.type == WebHTTPBody::Element::TypeData) {
+            post_param.type = content::WebHTTPPOSTBodyParams::TypeData;
+            post_param.data = "";
+            post_param.data.append(element.data.data(), element.data.size());
+            post_data.push_back(post_param);
+          } else if (element.type == WebHTTPBody::Element::TypeFile) {
+            post_param.type = content::WebHTTPPOSTBodyParams::TypeFile;          
+            #if defined(OS_POSIX)
+              post_param.filePath = base::SysWideToNativeMB(UTF16ToWideHack(element.filePath));
+            #elif defined(OS_WIN)
+              post_param.filePath = UTF16ToWideHack(element.filePath);
+            #endif
+            if (element.fileLength == -1) {
+              post_param.fileStart = 0;
+              post_param.fileLength = kuint64max;
+              post_param.modificationTime = base::Time().ToDoubleT();
+            } else {
+              post_param.fileStart = element.fileStart;
+              post_param.fileLength = element.fileLength;
+              post_param.modificationTime = element.modificationTime;
+            }
+            post_data.push_back(post_param);
+          } else if (element.type == WebHTTPBody::Element::TypeURL) {
+            GURL url = GURL(element.url);
+            DCHECK(url.SchemeIsFileSystem());
+            post_param.url = url;
+            post_param.fileStart = element.fileStart;
+            post_param.fileLength = element.fileLength;
+            post_param.modificationTime = element.modificationTime;
+            post_data.push_back(post_param);
+          } else if (element.type == WebHTTPBody::Element::TypeBlob) {
+          }
+        }
+        // Extract Header Info
+        WebString ContentType = request.httpHeaderField(WebString::fromUTF8("Content-Type"));
+        post_data[0].ContentType = "";
+        post_data[0].ContentType.append(ContentType.utf8().data(), ContentType.utf8().length());
+
+        OpenPostURL(frame, url, referrer, default_policy, post_data);

[michaeln, 2012/10/23 23:22:18]

return WebKit::WebNavigationPolicyIgnore here?

+      }
     }
   }