summaryrefslogtreecommitdiffstats
path: root/chrome_frame/plugin_url_request.h
Commit message (Collapse)AuthorAgeFilesLines
* TEST=new tests added.stoyan@chromium.org2010-02-011-60/+77
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrameAutomationClient class needs to be refcounted as it ↵ananta@chromium.org2009-11-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | implements the PluginRequestHandler interface which is maintained by individual requests which can outlive the active document/activex instances. I ran into a crash where UrlmonUrlRequest was calling into an invalid PluginRequestHandler pointer which had been destroyed just before. We also need to ensure that UrlmonUrlRequest and ChromeFrameActiveXBase select the multi threaded model as AddRef/Release can be invoked from multiple threads. I also removed the CleanupAsyncRequests function in ChromeFrameAutomationClient and moved all the code to CleanupRequests, which ensures that we treat synchronous and asynchronous requests similarly. There are instances where an automation client instance is created and destroyed without being initialized which causes a spurious assert to fire in the Uninitialize function. I added a check in the Uninitialize function to return if the state is uninitialized. Bug=none Review URL: http://codereview.chromium.org/386014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31792 0039d316-1c4b-4281-b951-d872f2087c98
* 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