New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 25643 link

Starred by 2 users

Issue metadata

Status: Verified
Last visit > 30 days ago
Closed: Oct 2009
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

chromeframe doesn't follow redirect

Reported by, Oct 23 2009

Issue description

ChromeFrame version: <from cf:about:version>
Google Chrome (Official Build 29618)
WebKit	532.3
V8	1.3.16
User Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.3 (KHTML, like 
Gecko) Chrome/ Safari/532.3

Related URL(s):
I'm having this issue with (use tilleryj2/password)
I created a simplified example here:

Steps to reproduce the issue:
click login link to GET login form
POST login form

What do you expect to happen?
should redirect to app root and then redirect into the application

What do you see instead?
hangs after post


Comment 1 by, Oct 25 2009

Hi Vishu

Thanks for the bug report and the test case. I will take a look at this and let you 


Comment 2 by, Oct 26 2009

Status: Assigned

Comment 3 by, Oct 27 2009

Labels: Mstone-4
Thanks for looking into this. I see it's been labeled Mstone-4. Is there somewhere I can look for more 
information about what that means? For example, what milestone is currently being worked on & what the 
timing is for Mstone-4?

Also, were you able to narrow down the issue any? Is there something I could change on my side to make the 
login work for chromeframe?


Comment 5 by, Oct 27 2009

The following revision refers to this bug: 

r30261 | | 2009-10-27 14:50:07 -0700 (Tue, 27 Oct 2009) | 30 lines
Changed paths:

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

Bug= 25643 

Review URL:

Comment 6 by, Oct 27 2009

Status: Fixed
Status: Verified
Works fine with CF (Official Build 31763)
Labels: -Area-ChromeFrame bulkmove Feature-ChromeFrame
Project Member

Comment 9 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 10 by, Mar 10 2013

Labels: -Mstone-4 -Feature-ChromeFrame M-4 Cr-ChromeFrame
Project Member

Comment 11 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment