Closed Bug 41950 Opened 25 years ago Closed 25 years ago

HTTP redirect to same URL fails (Login to My Yahoo! fails)

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cgohier, Assigned: dp)

References

(
URL
)

Details

(Whiteboard: [nsbeta3+])

Attachments

(2 files)

Patch to add in LOAD_REPLACE to loadFlags when redirecting.
4.35 KB, patch
Details | Diff | Splinter Review
Fixes url bar to show the redirected url. Needs previous patch.
1.31 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m16) Gecko/20000608 BuildID: 2000060808 Enter a login and password, hit Sign In. Nothing happens. If I reload, the correct page is loaded. Reproducible: Always Steps to Reproduce: 1. Go to URL (http://my.yahoo.com) 2. enter login and password 3. Press Sign in Actual Results: Nothing happens Expected Results: The personnalized page should load. Maybe a duplicate of bug 32783, but I don't think it's related to PSM.
I want to mark this works for me (as it does), but my build is 1 day older :) I did see how to make it so when you enter information and click "Sign in" it does nothing. In NS 4.x and Mozilla 6/7/00 if you enter an invalid username and password yahoo's login does then do nothing like described. cgohier@yahoo.com can you check again. This is not psm related.
confirming. happens exactly like Claude said. enter your valid user name & password, hit Sign In & no page loads. however if i refresh, the correct yahoo personalized page loads. using 2000060814 nightly build on windows 2000
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to Eric
Assignee: rods → pollmann
Tracing the network trafic, it looks like we are getting back the correct page from the server (after two redirects). I'm not sure why this page isn't displaying, looking into it...
Status: NEW → ASSIGNED
In this case, we start out on: A http://my.yahoo.com We then submit to: B http://login.yahoo.com/config/login We are redirected to: C http://login.yahoo.com/config/verify We are then redirected to: A http://my.yahoo.com It seems that if are on some page A, then attempt to load some page B, but get redirected back to A, we get this message in the console: Error loading URL B I've been able to reproduce this on a reduced test case locally, will clean up the source a bit and post...
Component: Form Submission → Networking
Passing this off to Netlib folks as it is surely a Necko problem. To see the reduced test case in action go here: http://blueviper/cgi-bin/time.cgi Here's the source (two files): pollmann blueviper(62):/home/httpd/cgi-bin> cat time.cgi #!/usr/bin/perl print "Content-Type: text/html\r \r <html><body>", `date`, "<br> Click <a href='nph-bounce.cgi'>here</a> to refresh. </body></html> "; pollmann blueviper(63):/home/httpd/cgi-bin> cat nph-bounce.cgi #!/usr/bin/perl $referrer = $ENV{'HTTP_REFERER'}; print "HTTP/1.0 302 Found\r Location: $referrer\r Connection: close\r Content-Type: text/html\r \r <html><body>Bad bad Leroy Brown.</body></html> ";
Assignee: pollmann → gagan
Status: ASSIGNED → NEW
Updating summary
Summary: Login to My Yahoo! fails → HTTP Refresh to same URL fails (Login to My Yahoo! fails)
Summary: HTTP Refresh to same URL fails (Login to My Yahoo! fails) → HTTP redirect to same URL fails (Login to My Yahoo! fails)
BTW, it looks like this code: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPChannel. cpp#1495 Which appears to cause the problem, was put there to fix the converse of this problem, bug 24884. Make sure not to reopen that when fixing this bug! :)
When looking at this redirect issue would it be worth looking at bug 22886 at the same time "redirects with no trailing CRLF after headers don't work" It does not sound like they are dupes, but they could be related and are assigned to different people.
-> myself
Status: NEW → ASSIGNED
Target Milestone: --- → M17
*** Bug 45649 has been marked as a duplicate of this bug. ***
I see this on some of trimble's intranet. ccing myself.
Is this a dup of 40658? Looks like it to me.
Blocks: 40658
*** Bug 40658 has been marked as a duplicate of this bug. ***
No longer blocks: 40658
taking over.
Assignee: gagan → dp
Status: ASSIGNED → NEW
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Assigned. Setting priority. Platform to all as I can reproduce this on linux.
Status: NEW → ASSIGNED
OS: Windows NT → All
Priority: P3 → P1
It's easy to fix. Just remove the check uri comparison check inside of OnRedirect of nsHTTPChannel
Thanks Ruslan. I see the check in nsHTTPChannel::Redirect() You just saved me a lot of time :-) Now to see how to break such dumb redirect loops of bug# 24884
Nope. Doesn't look like that check is the one blocking this. The sequence of urls we fetch is time.cgi -> nph-bounce.cgi -> time.cgi The check fails since it is now comparing nph-bounce.cgi with time.cgi So something else is preventing time.cgi from being fetched again. The cache checked out. It is obeying the expires that I added to time.cgi So something is blocking the refetch of time.cgi
Here is where it is failing. We are going from time.cgi -> nph-bounce.cgi fine. Then from there we get redirected to time.cgi back, the OnDataAvailable() for the fetch of time.cgi fails here. mChannel.mStatus = 0x804b0002 NS_IMETHODIMP nsHTTPServerListener::OnDataAvailable(nsIChannel* channel, nsISupports* context, nsIInputStream *i_pStream, PRUint32 i_SourceOffset, PRUint32 i_Length) { nsresult rv = NS_OK, channelStatus = NS_OK; PRUint32 actualBytesRead; if (mChannel) mChannel->GetStatus(&channelStatus) ; if (NS_FAILED(channelStatus)) // Canceled http channel return NS_OK; -- Here is the channel and uri structs from gdb: (gdb) p *mChannel $40 = {<nsIHTTPChannel> = {<nsIChannel> = {<nsIRequest> = {<nsISupports> = {_vptr. = 0x40e7d3a0 <nsHTTPChannel virtual table>}, }, }, }, <nsIInterfaceRequestor> = {<nsISupports> = {_vptr. = 0x40e7d388 <nsHTTPChannel::nsIInterfaceRequestor virtual table>}, }, <nsIProgressEventSink> = {<nsISupports> = {_vptr. = 0x40e7d36c <nsHTTPChannel::nsIProgressEventSink virtual table>}, }, <nsIProxy> = {<nsISupports> = {_vptr. = 0x40e7d340 <nsHTTPChannel::nsIProxy virtual table>}, }, <nsIStreamAsFile> = {<nsISupports> = {_vptr. = 0x40e7d320 <nsHTTPChannel::nsIStreamAsFile virtual table>}, }, mRefCnt = 10, _mOwningThread = 0x8067d30, mResponse = 0x0, mHandler = 0x81b1108, mRequest = 0x8883ed8, mHTTPServerListener = 0x86de770, mResponseContext = {<nsCOMPtr_base> = {mRawPtr = 0x0}, }, mCachedResponse = 0x87935d8, mProgressEventSink = {mRawPtr = 0x8883fb0}, mRealProgressEventSink = {mRawPtr = 0x867ab28}, mRequestStream = {mRawPtr = 0x0}, mWriteObserver = {mRawPtr = 0x0}, mOriginalURI = {mRawPtr = 0x885f518}, mURI = {mRawPtr = 0x8891368}, mReferrer = {mRawPtr = 0x0}, mEventSink = {mRawPtr = 0x8897270}, mRealEventSink = {mRawPtr = 0x867ab34}, mConnected = 1, mState = HS_WAITING_FOR_RESPONSE, mPrompter = {mRawPtr = 0x87966d0}, mRealPrompter = {mRawPtr = 0x8792910}, mCallbacks = {mRawPtr = 0x867a274}, mResponseDataListener = {mRawPtr = 0x86eeb88}, mBufOutputStream = {mRawPtr = 0x0}, mLoadAttributes = 16386, mLoadGroup = {mRawPtr = 0x867aba8}, mOwner = {<nsCOMPtr_base> = {mRawPtr = 0x0}, }, mCacheEntry = {mRawPtr = 0x8863dd8}, mCachedContentIsAvailable = 1, mCachedContentIsValid = 0, mFiredOnHeadersAvailable = 0, mFiredOpenOnStartRequest = 0, mFiredOpenOnStopRequest = 0, mAuthTriedWithPrehost = 0, mProxy = 0x0, mProxyPort = -1, mProxyType = 0x0, mProxyTransparent = 0, mBufferSegmentSize = 0, mBufferMaxSize = 0, mStatus = 2152398850, mCacheTransport = {mRawPtr = 0x0}, mPipeliningAllowed = 1, mPipelinedRequest = 0x0, mSecurityInfo = {<nsCOMPtr_base> = {mRawPtr = 0x0}, }, mStreamAsFileObserverArray = {mRawPtr = 0x866b758}, mApplyConversion = 1, mNotificationProxiesBuilt = 1, mOpenInputStreamHasEventQueue = 1} (gdb) p *(nsStdURL *)mChannel.mURI->mRawPtr $37 = {<nsIFileURL> = {<nsIURL> = {<nsIURI> = {<nsISupports> = {_vptr. = 0x40e77bc0 <nsStdURL virtual table>}, }, }, }, <nsIStandardURL> = {<nsISupports> = {_vptr. = 0x40e77b8c <nsStdURL::nsIStandardURL virtual table>}, }, mRefCnt = 4, _mOwningThread = 0x8067d30, fOuter = 0x889137c, fAggregated = {<nsISupports> = {_vptr. = 0x40e77c78 <nsStdURL::Internal virtual table>}, }, mScheme = 0x88915b0 "http", mUsername = 0x0, mPassword = 0x0, mHost = 0x866b7f8 "localhost", mPort = -1, mDirectory = 0x8891410 "/cgi-bin/", mFileBaseName = 0x8897298 "time", mFileExtension = 0x88972a8 "cgi", mParam = 0x0, mQuery = 0x0, mRef = 0x0, mURLParser = {mRawPtr = 0x8149430}, mDefaultPort = 80, static gStdURLParser = 0x81492d8, static gAuthURLParser = 0x8149430, static gNoAuthURLParser = 0x81494a0, mFile = {mRawPtr = 0x0}}
*** Bug 47906 has been marked as a duplicate of this bug. ***
DP as I mentioned to you in our discussion, the right thing to do here is that in the new channel that gets created in nsHTTPChannel::ProcessRedirect you need to set "skip the cache" flags so that we don't ever get the cached page on a redirect. Even though this makes us deviate from the spec a little, the whole world relies on the wrong implementation in 4.* and IE. So we should do what works. Let me know if you need more details and thanks for helping out on this.
*** Bug 48255 has been marked as a duplicate of this bug. ***
But the cache isn't the one that is doing the wrong things. The cache is doing right. The test case I am using is sending an expires for a previous time in time.cgi so it wont be cached.
I mean it wont ever be returned from the cache.
Ok got it. In nsWebShell.cpp there is a check like this. Since when we redirect we dont add in LOAD_REPLACE into the loadflags, this check passes when we are redirecting to the same url and hence, we kill the url load. nsWebShell::OnStartURLLoad(..) if (NS_SUCCEEDED(aURL->Equals(mCurrentURI, &equals)) && equals && !(loadFlags & nsIChannel::LOAD_REPLACE)) Stop(); Working on a patch to fix it.
I can login to yahoo with this patch (dont know if I should be happy about that!) Now the next problem is the url bar isnt getting updated with the redirected final url. mmh! looking...
What you are now seeing is bug 30783.
Ah ha. BTW, I have a reliable fix for it too. I used the same LOAD_REPLACE to detect redirect and use the right url to update location field. Necko is giving out a OnRedirect() and Gagan claims that is the only right way to do this. But then, that notification is comming in way too early to depend on it. We can fix it better once we fix that. Until then, the LOAD_REPLACE technique is a cheap way and works for 90% of cases. (I dont know what that other 10% is). Gagan ? The only drawback I see is that in this case, time.cgi get into history multiple times, once for each click. We need to work that in anyway we fix it (OnRedirect or LOAD_REPLACE). But then I am thinking, we can future that. Ccing mscott. This could potentially fix 30783 too. I need to test. I will add patch once my linux box can connect to network and test bug 30783 too.
*** Bug 46198 has been marked as a duplicate of this bug. ***
Bug 46198 also has a form post that gets a response of a HTTP redirect to the same URL. Dp's patch fixes that bug as well. Marked as a duplicate (above). Dp, you da man. :)
Your a lucky man dp. I just checked in changes last night to implement nsIHTTPEventSink so OnRedirects cause the method you modified in nsDocShell to get called properly. Good timing.... On a side note, I have pretty much identitcal code in my tree to solve another redirect bug I have. I'm still playing around with it to make sure it doesn't cause any regressions. So far so good. Your fix is pretty much the same thing as mine...
Good. I played with this and it works too. Since both our fixes are similar, I would say let us get your changes checked in and have QA run their redirect suite. We are ploughing through cache bugs. I might have to separate those changes from this patch and check them in separately.
Can you please check this in, so I can test the memberlogin on tripod.de, which MIGHT suffer from the same bug...thanks!
Ok talked with mscott. I am checking this in.
*** Bug 50609 has been marked as a duplicate of this bug. ***
All checked in. Thanks Eric for your wonderful test case.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
well the tripod login ain't fixed with this...I am not sure...maybe I should file a different bug... check it out: http://www.tripod.de/hpstudio/fmframeset/index.jsp login/pass: moztest/billyboy btw.: When this jsp coded html editor works with mozilla, I'll give it a two thumbs up...but there is way to go yet, from what I've seen last, as the login worked.
Using: userid: mozillatest2000 password: l1zard (note the '1' instead of an 'i') Marking VERIFIED FIXED on: - LinuxRH62 2000-09-07-08-M18 Commercial - Win98 2000-09-07-08-M18 Mozilla - MacOS86 2000-09-07-04-M18 Commercial
Status: RESOLVED → VERIFIED
*** Bug 53164 has been marked as a duplicate of this bug. ***
*** Bug 53330 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: