summaryrefslogtreecommitdiffstats
path: root/chrome_frame/plugin_url_request.h
Commit message (Collapse)AuthorAgeFilesLines
* Using thread safe reference counting to wrap the UploadData instance.Moving ↵tommi@chromium.org2009-10-291-10/+32
| | | | | | | | the post_data_len_ member variable to the PluginUrlRequest class.TEST=This is a tentative fix for bug 25531.BUG=25531 Review URL: http://codereview.chromium.org/340006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30432 0039d316-1c4b-4281-b951-d872f2087c98
* If a HTTP post to a server returns any redirect code other than 307, then ↵ananta@chromium.org2009-10-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Currently the host network stack in IE which uses Urlmon interfaces to initiateananta@chromium.org2009-10-241-1/+2
| | | | | | | | | | | | | | | | | | | | | and complete URL downloads requested by ChromeFrame, executes in the UI thread of IE. While this works fine in most cases for large data sizes, the IE UI thread ends up being busy pulling the data in our IBindStatusCallback::OnDataAvailable implementation. As a result the browser hangs until all data is pulled out. The fix is to handle Urlmon requests on a separate thread. This fixes http://code.google.com/p/chromium/issues/detail?id=24007 Changes to plugin_url_request.cc/.h are to set the LF property on these files. Bug=24007 Review URL: http://codereview.chromium.org/292035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29986 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+114
coming in a separate CL. BUG=None TEST=None Review URL: http://codereview.chromium.org/218019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27042 0039d316-1c4b-4281-b951-d872f2087c98