summaryrefslogtreecommitdiffstats
path: root/chrome_frame/http_negotiate.cc
Commit message (Collapse)AuthorAgeFilesLines
* Check if the url is a top level url before clearing the referrer header.tommi@chromium.org2010-04-231-16/+14
| | | | | | | | | TEST=n/a BUG=none Review URL: http://codereview.chromium.org/1745007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45391 0039d316-1c4b-4281-b951-d872f2087c98
* Only switch to cf for text/html. With opt-in URLs we could mark a URL to be ↵tommi@chromium.org2010-04-211-6/+10
| | | | | | | | | | | loaded in CF regardless of the target mime type. If CF turns around and wants to download the target, we would hit an infinite loop. TEST=Verify that issue 40046 is resolved. OptIn urls should work with the moniker patch and downloads should not cause an infinite loop. BUG=40046 Review URL: http://codereview.chromium.org/1715004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45226 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 44897 - Improved compatibility support for IE8.tommi@chromium.org2010-04-191-8/+10
| | | | | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 TBR=tommi@chromium.org Review URL: http://codereview.chromium.org/1659008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44919 0039d316-1c4b-4281-b951-d872f2087c98
* Improved compatibility support for IE8.tommi@chromium.org2010-04-181-10/+8
| | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44897 0039d316-1c4b-4281-b951-d872f2087c98
* With the ChromeFrame IMoniker patch in the referrer would not propagate ↵ananta@chromium.org2010-04-161-9/+22
| | | | | | | | | | | | | | | | | | | | correctly to Chrome when we switch from IE to CF. In ChromeFrame the referrer is set in the navigation manager which receives this in the IHttpNegotiate::BeginningTransaction patch. When we switch from IE to cF via the moniker patch we receive two calls to BeginningTransaction, the first one with the referrer and the other one without the referrer for the same URL causing the referrer to be overwritten. Fix is to handle this case. The referrer is cleared in our BeforeNavigate notification. I also moved some functions to chrome frame utils as part of this CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=41680 Bug=41680 Review URL: http://codereview.chromium.org/1653006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44733 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-5/+20
| | | | | | | | | | | | | | | | | | | | | onhttpequiv approach. There's a ton going on here. Brief summary: I'm introducing a caching layer for top level page requests that we then use again when switching the document from mshtml to cf. Also in this change list: * Removing the previous way of shifting the document moniker over to the worker thread when a new chrome document is created. Instead we use a request cache object. * Refactoring the part of the Bho class that offered access to it via TLS. This was needed for better testability but also makes (imho) the separation clearer and will possibly help in the future if we don't have a Bho object. * Added a bit of logging that I'd prefer to keep in there until we're confident enough with onhttpequiv. * Enabling two previously disabled tests (the ones I added for multiple requests) * Adding several more unit tests for the new code. Review URL: http://codereview.chromium.org/668187 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41495 0039d316-1c4b-4281-b951-d872f2087c98
* Releasing the IBindStatusCallback_PatchInfo patch after we've applied the ↵tommi@chromium.org2010-02-261-0/+6
| | | | | | | | | | | IInternetProtocolSink_PatchInfo one. TEST=Should be no change. If there is a regression because of this, it would be in the form of failing to switch to CF for pages that have the CF meta tag. BUG=none Review URL: http://codereview.chromium.org/660032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40144 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for referrer flakyness. There were two problems:tommi@chromium.org2010-02-181-0/+10
| | | | | | | | | | | | | | | Grabbing the referrer header when the request is made and not in BeforeNavigate2. The request headers aren't always available in BeforeNavigate2. Mshtml provides these headers in IHttpNegotiate::BeginningTransaction, which is where we now grab them. There was a race in chrome_frame_automation.cc where we use std::string to store the referrer url and then access that string from different threads. This was causing the referrer URL to be missing at some times and at other times be sent over to chrome as bad string (e.g. containing embedded nulls) and subsequently be deemed an invalid URL and dropped. TEST=Fixes referrer header flakyness. BUG=34812 Review URL: http://codereview.chromium.org/646013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39383 0039d316-1c4b-4281-b951-d872f2087c98
* Handle a case where the document is being served up from cache. In that ↵tommi@chromium.org2010-02-041-1/+26
| | | | | | | | | | | case we have to get to the browser service object via a different set of QS calls. TEST=This is a part of the onhttpequiv effort. For now there won't be any visible changes since onhttpequiv is disabled but once it becomes enabled again, CF will be detected for cached pages as well as non-cached. BUG=none Review URL: http://codereview.chromium.org/573012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38132 0039d316-1c4b-4281-b951-d872f2087c98
* TEST=new tests added.stoyan@chromium.org2010-02-011-3/+41
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for an issue we were seeing with wave.tommi@chromium.org2010-01-231-12/+14
| | | | | | | | | | | | | | | After switching over to using the onhttpequiv notification from mshtml we can expect to see sub frames being created even before the owning document has completed loading. In particular frames whose source is about:blank. TEST=Google Wave should work. BUG=32904 Review URL: http://codereview.chromium.org/543180 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36945 0039d316-1c4b-4281-b951-d872f2087c98
* Fix FullTabModeIE_ChromeFrameDeleteCookieTest. The problem was that a ↵tommi@chromium.org2010-01-211-0/+2
| | | | | | | | | | | | | | | domain cookie was being set twice although only set once by the server. The test itself needed fixing as well as an extra check for domain cookies set by a different url than the current url. There's one other problem remaining however which was initially reported in bug 30786 and I'll get on that next (bug reopened). TEST=Run the FullTabModeIE_ChromeFrameDeleteCookieTest test. BUG=32546, 30786 Review URL: http://codereview.chromium.org/546104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36749 0039d316-1c4b-4281-b951-d872f2087c98
* Updates for onhttpequiv. Preserving the referrer header, zapping the ↵tommi@chromium.org2010-01-161-2/+4
| | | | | | | | | | | | | currently loading document to prevent small documents from executing code. I'm not enabling httpequiv just yet as there are a couple of things I'm working on related to tests that will break once I make the switch. TEST=There should be no change since the code isn't still active but run all tests just to be safe. BUG=none Review URL: http://codereview.chromium.org/545096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36436 0039d316-1c4b-4281-b951-d872f2087c98
* Use the OnHttpEquiv notification to switch to CF when the http-equiv meta ↵tommi@chromium.org2009-12-111-22/+36
| | | | | | | | | | | | | | | | tag is detected. This implementation is still behind the registry switch (set PatchProtocols to 0 in the registry). I will switch over to it wholesale in a separate patch. We use the same mechanism for re-initiating the navigation we use to transfer downloads over to the host, so I moved the common code to utils.cc and added NavigateBrowserToMoniker. When we see a browser instance attempting to load a CF document, we raise a TLS flag that we catch in HttpNegotiatePatch::ReportProgress when the mime type is being reported. This is the same place where we examine http headers and report the mime type. BUG=n/a TEST=Set PatchProtocols (REG_DWORD) to 0 in the CF HKCU config key and make sure we detect and handle the meta tag as well or better than before. Review URL: http://codereview.chromium.org/489004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34366 0039d316-1c4b-4281-b951-d872f2087c98
* Limit the X-UA-Compatible HTTP header-based altering of the mime type ↵robertshield@chromium.org2009-12-041-30/+33
| | | | | | | | | | | performed by Chrome Frame to top-level requests only in IE. BUG=having an iframe that requests a resource that includes the X-UA-Compatible header in the response will trigger CF taking over the page. TEST=BUG doesn't happen anymore. Review URL: http://codereview.chromium.org/465036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33849 0039d316-1c4b-4281-b951-d872f2087c98
* Remove erroneous DCHECK that is reached when loading pages that don't call ↵robertshield@chromium.org2009-12-031-10/+19
| | | | | | | | | | | | | | | out to wininet like about:blank. Altering constant name pulled in from latest platform SDK to avoid naming conflicts for those with said SDK. Add slightly more logging to error messages. BUG=DCHECK hit when loading about:blank. TEST=Load about:blank in a debug build and no DCHECK is seen. Review URL: http://codereview.chromium.org/465030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33706 0039d316-1c4b-4281-b951-d872f2087c98
* Adding support for Chrome Frame to be loaded via the presence of an ↵robertshield@chromium.org2009-12-031-0/+101
| | | | | | | | | | | | | X-UA-Compatible HTTP header (in addition to the meta tag support). Also pins the CF module into the process such that it won't get unloaded. Doing this to work around how we can get unloaded without unpatching properly. BUG=22802 TEST=Navigate to a web site whose server sends the X-UA-Compatible: chrome=1 HTTP header and ensure that the page is loaded in CF. Review URL: http://codereview.chromium.org/465009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33629 0039d316-1c4b-4281-b951-d872f2087c98
* Add the chromeframe tag to the user agent header at runtime instead of ↵tommi@chromium.org2009-10-171-0/+164
statically in the registry.TEST=Try disabling GCF and see if the chromeframe tag in the user agent is still set. It should not be. Also make sure you don't have an older version installed... the chromeframe tag should not be in the registry - if it is, you've got an older version still registered. This should fix the issue with going to wave.google.com after disabling chrome frame and seeing the white page of death.R=amitBUG=22760 Review URL: http://codereview.chromium.org/259025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29370 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-22 23:50:41 +0000