Closed
Bug 823888
Opened 12 years ago
Closed 9 years ago
Mixed-content redirect ends up at referer rather than destination
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: timothy.morgan, Unassigned)
Details
(Keywords: testcase-wanted, Whiteboard: [necko-backlog])
Attachments
(1 file)
93.91 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232
Steps to reproduce:
Cleared all cookies and cache,
Requested my application,
Redirected (302) to a login page on a secure server on a separate domain,
Submitted login credentials,
Redirected (302) back to my application with login token in URL,
Application validates token, then redirects (302) back to itself again to remove token from URL
Actual results:
The final redirect to remove the token actually sends me back to the login URL., causing an infinite redirect loop, along with the "firefox has detected that your request is redirecting in a way that will never complete" message.
http://support.mozilla.org/en-US/questions/933001?esab=a&s=redirect&r=2&as=s seems to describe a similar scenario; however, this only happens in one browser for me (as noted in the next box).
In the attached screenshot, the web console shows the POST for the login credentials at the top, followed by the redirect back to the application with the login token appended to the URL. The request inspection dialog shows the response-header received from the second request as being the application URL minus the parameter suffix. Yet, as you can see, the third request in the list is in fact back to the login URL.
There is no referer shown in the request-header in the inspector for the second request in the list, so I'm unsure how it could be ending up there...?
Expected results:
It should have redirected to the place in the 302 response header, shown in the request inspection window to be http://baboon/~tjm/answrs/appshare/nodesweb/pub/
If I click try again, or manually request that URL, with or without the parameter suffix, it works fine - so it appears to just be after the first redirect from https that this happens.
The problem doesn't occur in any of the other browsers I tested, which were Chrome (latest) and IE8 and the old FF3.6.
Reporter | ||
Comment 1•12 years ago
|
||
I've just tried the system under ff 17.0.1 in Ubuntu and was unable to reproduce - so I have only seen this under 17.0.1 in Windows XP now. I will attempt to construct the scenario on a public web page as soon as I can. Thanks.
Yes, it would be great if you could add a minimal testcase, like online webpage or HTML code, to test.
Keywords: testcase-wanted
Updated•9 years ago
|
Whiteboard: [necko-backlog]
Comment 3•9 years ago
|
||
Considering the fact that the reporter did not provided more information, I will mark this issue as resolved - incomplete.
If you can still reproduce this, feel free to reopen it and provide the requested information.
Thanks,
Cosmin.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(timothy.morgan)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•