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 47656382cd878faa2d2d0e146d5c3e8a25f17a09..a429a80108d0d95614be26837ba6c5bef22b7cac 100644
--- a/content/renderer/render_view_impl.cc
+++ b/content/renderer/render_view_impl.cc
@@ -185,6 +185,7 @@
 #include "webkit/glue/alt_error_page_resource_fetcher.h"
 #include "webkit/glue/dom_operations.h"
 #include "webkit/glue/glue_serialize.h"
+#include "webkit/glue/resource_request_body.h"
 #include "webkit/glue/web_intent_service_data.h"
 #include "webkit/glue/webdropdata.h"
 #include "webkit/glue/webkit_constants.h"
@@ -320,6 +321,7 @@ using base::TimeDelta;
 
 using webkit_glue::AltErrorPageResourceFetcher;
 using webkit_glue::ResourceFetcher;
+using webkit_glue::ResourceRequestBody;
 using webkit_glue::WebPreferences;
 using webkit_glue::WebURLResponseExtraDataImpl;
 
@@ -1132,22 +1134,48 @@ 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

[michaeln, 2012/11/05 23:38:29]

Since this isn't always for cross-process post handling the comment could be
misleading. Would be better to remove it i think.

[irobert, 2012/11/06 05:39:20]

Done.

+    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()));
+      const std::vector<ResourceRequestBody::Element>* uploads =
+          params.browser_initiated_post_data->elements();
+      std::vector<ResourceRequestBody::Element>::const_iterator iter;
+      for (iter = uploads->begin(); iter != uploads->end(); ++iter) {
+        switch (iter->type()) {
+          case ResourceRequestBody::Element::TYPE_BYTES: {
+            http_body.appendData(WebData(iter->bytes(),
+                                         static_cast<int>(iter->length())));
+            break;
+          }
+          case ResourceRequestBody::Element::TYPE_FILE: {
+            http_body.appendFileRange(
+                WebString::fromUTF8(iter->path().value()),
+                static_cast<long long>(iter->offset()),
+                static_cast<long long>(iter->length()),
+                iter->expected_modification_time().ToDoubleT());
+            break;
+          }
+          case ResourceRequestBody::Element::TYPE_FILE_FILESYSTEM: {
+            CHECK(false);
+            break;
+          }
+          case ResourceRequestBody::Element:: TYPE_BLOB: {
+            CHECK(false);
+            break;
+          }
+          default:
+            NOTREACHED();
+        }
+      }
       request.setHTTPBody(http_body);
+      request.setHTTPMethod(WebString::fromUTF8("POST"));

[michaeln, 2012/11/05 23:38:29]

If it's OK to assume POST as the method here, great! . What happens with content
like <form action="x" method="PUT">?

[irobert, 2012/11/06 05:39:20]

We can assume this from the original code, this piece of code only deals with
POST submission. It is also important to support PUT or DELETE method even they
are not supported in HTML5. I will keep investigate whether the httpbody is
different for these methods.

On 2012/11/05 23:38:29, michaeln wrote:

[michaeln, 2012/11/06 22:18:41]

Not sure i follow. If content shows up that looks like <form action='x'
method='PUT'> what happens, do we not end up in this block of logic (maybe we
dont)? And if not, what happens when a <form> element like like that is
submitted? I don't know if content like that is valid or how its currently
handled by chrome, but if handling of forms with methods other than "POST"
involve navigating frames and uploading data to servers in the body of an HTTP
msg, we'd want to do the cross-site magic for there too and retain the same HTTP
method names and bodies seen by servers in the current impl.

Please let us know what you find out about forms with other method names.

[irobert, 2012/11/06 22:25:45]

PUT method submission will not end up in this block. The result for a PUT method
submission will lost all the form data due to the process swap. I do agree with
you that we also need to support there. I will investigate on how PUT method
submission works.

On 2012/11/06 22:18:41, michaeln wrote:

+      request.setHTTPHeaderField(
+          WebString::fromUTF8("Content-Type"),
+          WebString::fromUTF8(params.extra_headers));
     }
-
     main_frame->loadRequest(request);
   }
-
   // In case LoadRequest failed before DidCreateDataSource was called.
   pending_navigation_params_.reset();
 }
@@ -1664,6 +1692,22 @@ void RenderViewImpl::OpenURL(WebFrame* frame,
       frame->identifier()));
 }
 
+// Handle cross-process Post submit Navigation.
+void RenderViewImpl::OpenPostURL(
+    WebFrame* frame,
+    const GURL& url,
+    const Referrer& referrer,
+    WebNavigationPolicy policy,
+    const ViewMsg_PostRequest_Params& request) {
+  Send(new ViewHostMsg_OpenPostURL(
+      routing_id_,
+      url,
+      referrer,
+      NavigationPolicyToDisposition(policy),
+      frame->identifier(),
+      request));
+}
+
 // WebViewDelegate ------------------------------------------------------------
 
 void RenderViewImpl::LoadNavigationErrorPage(
@@ -2727,7 +2771,58 @@ WebNavigationPolicy RenderViewImpl::decidePolicyForNavigation(
     if (!net::RegistryControlledDomainService::SameDomainOrHost(frame_url,
                                                                 url) ||
         frame_url.scheme() != url.scheme()) {
-      OpenURL(frame, url, referrer, default_policy);
+      WebString method = request.httpMethod();
+      if(method != WebString("POST")) {
+        OpenURL(frame, url, referrer, default_policy);
+      } else {
+        scoped_refptr<ResourceRequestBody> request_body =
+            new ResourceRequestBody();
+        WebHTTPBody body = request.httpBody();
+        WebKit::WebHTTPBody::Element element;
+        for (int i=0; body.elementAt(i, element); i++) {
+          switch (element.type) {
+            case WebHTTPBody::Element::TypeData:
+              if (!element.data.isEmpty())
+                request_body->AppendBytes(
+                    element.data.data(), static_cast<int>(element.data.size()));
+              break;
+            case WebHTTPBody::Element::TypeFile: {
+              if (element.fileLength == -1) {
+                request_body->AppendFileRange(
+                    FilePath(element.filePath.utf8()),
+                    0, kuint64max, base::Time());
+              } else {
+                request_body->AppendFileRange(
+                    FilePath(element.filePath.utf8()),
+                    static_cast<uint64>(element.fileStart),
+                    static_cast<uint64>(element.fileLength),
+                    base::Time::FromDoubleT(element.modificationTime));
+              }
+              break;
+            }
+            case WebHTTPBody::Element::TypeURL: {
+              CHECK(false);
+              break;
+            }
+            case WebHTTPBody::Element::TypeBlob:
+              CHECK(false);
+              break;
+            default:
+              NOTREACHED();
+          }
+        }
+
+        // Extract Header Info.
+        WebString ContentType =
+            request.httpHeaderField(WebString::fromUTF8("Content-Type"));
+        std::string ContentTypeStr (ContentType.utf8().data(),
+                                    ContentType.utf8().length());
+
+        ViewMsg_PostRequest_Params params;
+        params.extra_header = ContentTypeStr;
+        params.request_body = request_body;
+        OpenPostURL(frame, url, referrer, default_policy, params);
+      }
       return WebKit::WebNavigationPolicyIgnore;
     }
   }