If a HTTP post to a server returns any redirect code other than 307, then browsers don't preserve the

request method, i.e. they convert the POST request to GET. For 307 redirects browsers preserve redirects.

This CL fixes the following issues :-
1. As per the above description, we reset the method which 
   ensures that we don't generate the post related headers.
   The Post302RedirectGet net test does test this very case.
   However it works correctly as Chrome follows the redirect  
   and reissues the GET request. In this case this does not 
   occur as the only calls which are invoked on the bind 
   status callback after the redirect are GetBindInfo and
   BeginningTransaction where we incorrectly return the post
   related information. Ideally we would want to turn off
   follow redirects in Urlmon or Chrome. I tried the latter
   which has a number of issues. 

2. In debug mode the chrome_frame_net_tests cause a DCHECK 
   to be fired which indicates that the test is not being     
   run on the UI thread.

3. As the Urlmon requests are now destroyed asynchronously 
   having a DCHECK after the Stop call on the Urlmon
   request object in the CleanupAsyncRequests function is 
   incorrect. Removed this DCHECK

Fixes bug http://code.google.com/p/chromium/issues/detail?id=25643

Bug=25643

Review URL: http://codereview.chromium.org/333043

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30261 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 11 insertions, 0 deletions

diff --git a/chrome_frame/urlmon_url_request.cc b/chrome_frame/urlmon_url_request.cc
index d64cc62..45634b7 100644
--- a/chrome_frame/urlmon_url_request.cc
+++ b/chrome_frame/urlmon_url_request.cc
@@ -168,6 +168,17 @@ STDMETHODIMP UrlmonUrlRequest::OnProgress(ULONG progress, ULONG max_progress,
       // Fetch the redirect status as they aren't all equal (307 in particular
       // retains the HTTP request verb).
       redirect_status_ = GetHttpResponseStatus();
+      // NOTE: Even though RFC 2616 says to preserve the request method when
+      // following a 302 redirect, normal browsers don't do that. Instead they
+      // all convert a POST into a GET in response to a 302 and so shall we.
+      // For 307 redirects, browsers preserve the method.  The RFC says to
+      // prompt the user to confirm the generation of a new POST request, but
+      // IE omits this prompt and so shall we.
+      if (redirect_status_ != 307 &&
+          LowerCaseEqualsASCII(method(), "post")) {
+        set_method("get");
+        post_data_len_ = 0;
+      }
       break;
 
     default: