From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020222 BuildID: 2002022208 when I go to www.photoandmore.de, I get the following message: Redirection limit for this URL exceeded. Unable to load the requested page Reproducible: Always Steps to Reproduce: 1. go to www.photoandmore.de Actual Results: you get the the mentioned message in the lower frame Expected Results: it should just display the page. with Bug 115252 there was a similar bug, but that is marked fixed. If you want to mark this as a duplicate of bug 115252, then please reopen that one. I wasn't sure if I should open a new bug or reopen the old one ... the URL of the problematic lower frame is http://s7723726.shoplite.de I saw several other website with this behaviour (eg. http://www.bacowa.de/shop/index.html), so this is a major bug IMHO. These pages load fine with every other browser I tried, even NS6.1, so this is no evang bug.

just to make it clear, yes I created a new profile just to check if it corrects this problem (as suggested in 115252) but it did not fix the problem

I can see the problem on win32 with an 2h old build. I can't see it with my second test profile.. (my normal profile is 1month old) The problematic URL: http://s7723726.shoplite.de/sess/utn153c76d8b53930d/ it should redirect to : http://s7723726.shoplite.de/sess/utn153c76d8b53930d/shopdata/index.html but mozilla fails ... BTW: I accept all cookies

-> badami for investigation

Was able to reproduce this once. At that point, it looked like it was recursing as a result of // If we were only granted read access, then assume the entry is valid. if (mCacheAccess == nsICache::ACCESS_READ) { mCachedContentIsValid = PR_TRUE; return NS_OK; } Is this for offline browsing support ? It never seemed to be going to the net but picking up the local cached entry.

from Mattis logfile: 0[264268]: nsHttpChannel::ReadFromCache [this=f44608] Using cached copy of: http://s7723726.shoplite.de/sess/utn153c76d8b53930d/ 0[264268]: nsHttpChannel::CloseCacheEntry [this=1b4d088 status=0] 0[264268]: nsHttpChannel::HandleAsyncRedirect [this=f44608] 0[264268]: nsHttpChannel::ProcessRedirection [this=f44608 type=301] 0[264268]: redirecting to: http://s7723726.shoplite.de/sess/utn153c76d8b53930d/ [redirection-limit=9] while I don't really know what I am talking about it looks like the page redirects to itself. this happens the other times too, such eventually the redirection limit ... btw: that this page works fine with my mozilla at home (20020126)

seems that it works perfectly at home, even with a CSV build... so this problem seems to be triggered only under certain circumstances, but then always.

vinay: yes, that code is for offline support.

Need help in getting this reproduced.

I see this at http://www.globaldirect.co.uk too on Windows 2000 build 2002022308 (the site works OK in, dare I say it, IE6)

set NSPR_LOG_MODULES=nsHttp:5 set NSPR_LOG_FILE=http.log Repeat ur experiment. Attach http.log to this bug report once the problem happens.

here is a logfile. as I described above, the problem always shows at my computer at work (compiled binary from mozilla.org) but not at the computer at home (self compiled from csv). I don't know, if there are other differences...

Darin U think that in nsHttpChannel::CheckCache() rv = mCacheEntry->GetExpirationTime(&time); if (NS_FAILED(rv)) return rv; if (NowInSeconds() <= time) With the granularity being in terms of seconds, should this check be just a "<" rather than the "<=" ??

jens: any chance you could clear your cache and recapture the http log? thx! vinay: we don't know what the server specified as the expiration time.. and w/o knowing the expiration time it's impossible to determine what is really going wrong. it may be that now == expirationTime, but we need more evidence.

darin: I clreared the cache via edit->preferences->advanced->cache and remade the logfile. I hope it helps to find the problem.

this appears to be a server misconfiguration... for starters, the server is sending back a "301 Moved Permanently" redirect w/ a Location header pointing to the URL that resulted in the 301 response. it doesn't make any sense for the server to do this, since a 301 is supposed to be cached by the client. see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 here's the 301 redirect response: 1026[810b718]: http response [ 1026[810b718]: HTTP/1.1 301 OK 1026[810b718]: Date: Wed, 27 Feb 2002 17:00:16 GMT 1026[810b718]: Server: Apache/1.3.22 (Unix) 1026[810b718]: P3P: CP="NOR CUR OUR NOR UNI STA" 1026[810b718]: X-Powered-By: PHP/4.1.1 1026[810b718]: Location: http://s7723726.shoplite.de/sess/utn153c7d109f90146/ 1026[810b718]: Keep-Alive: timeout=5, max=199 1026[810b718]: Connection: Keep-Alive 1026[810b718]: Transfer-Encoding: chunked 1026[810b718]: Content-Type: text/html 1026[810b718]: ] notice that it's "301 OK" ... that seems odd. of course, the "OK" is ignored, but typically servers say "301 Moved Permanently" or something similar. cc'ing morse in case there's anything interesting in the cookies.

but why depends this on the profile ?

matti: if i understand your question correctly... clearing the cache before generating the log file resulted in a log file containing all of the request/response headers up until the point of failure. the original log file was generated from a full cache. so, it wasn't very useful.

no, i mean : It doesn't work with my main profile (with cleared caches) = redirection error It works with my second test profile. I accept all cookies in both profiles.

matti: hmm... i'm not sure what that could mean.

Darin The OK is something that we are adding on. It seems to have sent us 301 without the statusText. This is odd, but permissible since Reason-Phrase = *<TEXT, excluding CR, LF> 1026[810b718]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 301] 1026[810b718]: mal-formed response status line; assuming statusText = 'OK' 1026[810b718]: Have status line [version=11 status=301 statusText=OK] Jens-Uwe Since u r able to build from source and reproduce the problem, can u try the fix i suggested ? Feel free to mail me for any help u may need.

vinay: I build it at home from CSV, but I can't reproduce the problem there at all :-/ I'll try to build it here at work and ask again, if I have problems!

Jen U can apply this patch and try. The changes are 1. Lot more of logging to figure out what is going wrong. 2. change from <= to <

just a stupid question: how do I use this patch? Patch always asks me 'which file to patch?'. Which options do I have to use, in which folder do I have to start the patch program? I am under linux... I now build Mozilla here at work and the bug still shows. I even have the debug-informations enabled, because i forgot to disable them, but maybe this helps you somewhat? I'll attach the debug output while loading the page. Please note the 'Opening file cookies.txt failed' messages, but thats the only strange looking thing for me.

vinay: the problem sadly survived applying the patch. here is the log file you wanted. I hope it gives you enough input, since I won't be able to test anything at this computer until monday morning (european time).

what I thought after seeing the log: 1024[809e330]: http request [ 1024[809e330]: GET /sess/utn153c7eb0e461a8b/ HTTP/1.1 1024[809e330]: Host: s7723726.shoplite.de 1024[809e330]: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020228 1024[809e330]: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 1024[809e330]: Accept-Language: de 1024[809e330]: Accept-Encoding: gzip, deflate, compress;q=0.9 1024[809e330]: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 1024[809e330]: Keep-Alive: 300 1024[809e330]: Connection: keep-alive 1024[809e330]: Cookie: sl28336343=utn153c7eb0e461a8b 1024[809e330]: Referer: http://www.photoandmore.de/ 1024[809e330]: ] [...] 1026[81240c8]: mSource->Read [rv=0 count=4096 countRead=316] 1026[81240c8]: nsHttpTransaction::ParseHead [count=316] 1026[81240c8]: nsHttpTransaction::ParseLine [HTTP/1.1 301] 1026[81240c8]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 301] 1026[81240c8]: mal-formed response status line; assuming statusText = 'OK' 1026[81240c8]: Have status line [version=11 status=301 statusText=OK] 1026[81240c8]: nsHttpTransaction::ParseLine [Date: Thu, 28 Feb 2002 22:36:21 GMT] 1026[81240c8]: nsHttpTransaction::ParseLine [Server: Apache/1.3.22 (Unix)] 1026[81240c8]: nsHttpTransaction::ParseLine [P3P: CP="NOR CUR OUR NOR UNI STA"] 1026[81240c8]: nsHttpTransaction::ParseLine [X-Powered-By: PHP/4.1.1] 1026[81240c8]: nsHttpTransaction::ParseLine [Location: http://s7723726.shoplite.de/sess/utn153c7eb0e461a8b/] 1026[81240c8]: nsHttpTransaction::ParseLine [Keep-Alive: timeout=5, max=199] 1026[81240c8]: nsHttpTransaction::ParseLine [Connection: Keep-Alive] 1026[81240c8]: nsHttpTransaction::ParseLine [Transfer-Encoding: chunked] 1026[81240c8]: nsHttpTransaction::ParseLine [Content-Type: text/html] 1026[81240c8]: nsHttpResponseHead::ParseContentType [type=text/html] 1026[81240c8]: nsHttpTransaction::HandleContent [this=8799f18 count=0] 1026[81240c8]: nsHttpTransaction::HandleContentStart [this=8799f18 response-head=428007b0] 1026[81240c8]: http response [ 1026[81240c8]: HTTP/1.1 301 OK 1026[81240c8]: Date: Thu, 28 Feb 2002 22:36:21 GMT 1026[81240c8]: Server: Apache/1.3.22 (Unix) 1026[81240c8]: P3P: CP="NOR CUR OUR NOR UNI STA" 1026[81240c8]: X-Powered-By: PHP/4.1.1 1026[81240c8]: Location: http://s7723726.shoplite.de/sess/utn153c7eb0e461a8b/ 1026[81240c8]: Keep-Alive: timeout=5, max=199 1026[81240c8]: Connection: Keep-Alive 1026[81240c8]: Transfer-Encoding: chunked 1026[81240c8]: Content-Type: text/html 1026[81240c8]: ] the browser loads page X and gets a 301, saying it should better go to page Y, which happens to be the same page... I guess that here the server should give a different location?

jens-uwe: see comment #15... the server appears to be misconfigured.

Jens-Uwe, With my patch applied can u submit one more log from the profile which works correctly ? Sorry, but this seems a bit of a bummer and need more data to come to exact conclusions. Also, can u install a network tracer like ethereal and try the same with IE and then submit a packet trace ? Thanks for all the help.

Additional info. Telnetting to our proxy server and doing: GET http://www.globaldirect.co.uk HTTP/1.0 results in the following relevant headers (irrelevant headers omitted): HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.0 Location: ?sn=2084984222 <body><h1>Object Moved</h1>This object may be found <a HREF="?sn=2084984222">here</a>.</body> In this case, the server doesn't seem to be misconfigured - it's just sending back a session ID [which is unique - if I repeat the experiment, I get a different ?sn= number back] which seems quite reasonable. Interestingly, I asked for HTTP/1.0 and it gave me HTTP/1.1 back but that's probably a red herring. BUT: If I repeat the get, adding on the ?sn=xxxxxx GET http://www.globaldirect.co.uk/?sn=2084984222 HTTP/1.0 I get the SAME headers back as I quote above, but a DIFFERENT number in the location: sn= header (and the href). Also doing a snoop between my Mozilla client and the proxy server shows the same thing - request the page, get a 302 response with a unique number, repeat the request with that new number, get a 302 back with another number, repeat.... until it gives up with the error message. However, snooping IE6 client, the same thing happens. I get 5 unique numbers, but then it gets an HTTP/1.0 200 OK and the page comes up anyway. So what is IE doing differently on the 5th attempt? Is it sending something else to stop the redirection? Maybe this will help you nice chaps.

Great stuff, can u please attach the results of ur snoop from Mozilla and IE. thanks for all.

Hi, this is weird and getting weirder. I tried to repeat http://www.globaldirect.co.uk so I could capture the snoop, and the web page works now! The only explanation I can come up with at the moment is that because I got through successfully with IE6, something was cached in the proxy server. Then when using Moz again, the proxy server served up the cached something. I can't clear the proxy cache as it is a live machine, but I'll see if I can repeat some other way. I tried the other problem URL www.photoandmore.de and the problem shows up there. I tried the problem URL http://s7723726.shoplite.de/ directly and Moz complains immediately about the redirection without even contacting the proxy server, so it seems to have got it stuck in its cache. Changing the cache setting from 'out of date' to 'everytime' gave me something in the snoop. It is adding on a session ID, but it is the SAME session ID every time, and so this DOES appear to be a server error. Trying http://s7723726.shoplite.de/ in IE6 is even worse. It produced a 25Mb snoop file before IE6 came up with a generic cannot find server or DNS error message. The snoop file is full of the same Location: headers (same session ID every time). However, visiting the parent site http://www.photosandmore.de works just fine in IE6. Bizarre. Revisiting http://www.photosandmore.de in Mozilla after visiting it in IE works just fine. I assume this is because the proxy server has cached it. Very strange! Attached is the snoop when Mozilla was the client and before IE6 was used trying to access http://s7723726.shoplite.de. I don't have a snoop when it was trying to access http://www.photosandmore.de before it started working :-(. The badami site works fine for me. I will snoop again if I find another site that doesn't work. Hope this helps.

perhaps this is a proxy server caching bug of some sort. 302 redirects should never be cached by a proxy server.

also, shift-reload should cause mozilla to bypass the proxy server's cache.

FYI, using mozilla-0.9.7-0 (RH rawhide rpm) I got this message consistently by:- accessing www.nytimes.com - pressing middle mouse button to open link in new window I don't seem to get that behavior with mozilla-0.9.9-0 (RH RPMs from mozilla.org), but I do now get it consistently trying to access a secure web site at my university. Although I've been unable to access it using any version of Mozilla released in the past 6 months or so (things are fine with NS and IE) the behavior was to just dump me back to the non-secure starting page; now it gives the redirect message. I can gather more info on this, unless this bug is deemed to be a server misconfiguration issue, it would probably be good to give some info on what an end-user could tell a site administrator to convince them they have a problem.

spn@ucdavis.edu: 0.9.7 is old and your problem is fixed....

I believe he is saying that he has the problem with 0.9.9 but at a different site.

actually, shawn, you might be able to gather some information for us corresponding to the failure you're still seeing on the secure website. can you set the following environment variables before running mozilla: set NSPR_LOG_MODULES=nsHttp:5 set NSPR_LOG_FILE=http.log then run mozilla, repro the problem, and finally attach "http.log" to this bug report. thx!

Comment on attachment 74310 [details] [diff] [review] doom cache entry if redirecting back to self sr=darin

Comment on attachment 74310 [details] [diff] [review] doom cache entry if redirecting back to self r=gagan

Comment on attachment 74310 [details] [diff] [review] doom cache entry if redirecting back to self >@@ -1239,6 +1243,14 @@ > rv = ioService->NewURI(nsDependentCString(location), nsnull, mURI, > getter_AddRefs(newURI)); > if (NS_FAILED(rv)) return rv; >+ >+ // Kill the current cache entry if we are redirecting >+ // back to ourself. >+ PRBool redirectingBackToSameURI = PR_FALSE; >+ if (mCacheEntry && (mCacheAccess & nsICache::ACCESS_WRITE) && >+ NS_FAILED(mURI->Equals(newURI, &redirectingBackToSameURI)) && Shouldn't that be NS_SUCCEEDED, not NS_FAILED? >+ redirectingBackToSameURI) >+ mCacheEntry->Doom(); > > // move the reference of the old location to the new one if the new > // one has none. /be

yes it should be. Will fix at checkin.

Comment on attachment 74310 [details] [diff] [review] doom cache entry if redirecting back to self a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Fixed with checkin C:\mozilla\netwerk\protocol\http\src>cvs commit cvs commit: Examining . Checking in nsHttpChannel.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v <-- nsHttpChann el.cpp new revision: 1.100; previous revision: 1.99 done

I just downloaded the nightly build (mozilla-i686-pc-linux-gnu.tar.gz) which I think is the first to incorporate Vinay's patch. I am now able to access the secure web site I previously was <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=127348#c35>unable to access</a>. Thanks. This is a long-standing bug (I looked at my notes and I've had the same problem since 0.9.2) and it's nice to have it fixed.

Aha. I think this patch might also fix another bug involving groups.yahoo.com? I've been unable to login using "secure" mode when starting at groups.yahoo.com--it accepts my username and password but dumps me back at groups.yahoo.com as if I had not logged in. However, I *have* been able to login using non-secure, or by using the secure mode at, say, mail.yahoo.com then going to groups. The latest build allows me to successfully login at groups.yahoo.com using the secure mode. I did a few searches in bugzilla, but I don't see any likely duplicates.

shawn: i suspect you were really seeing bug 114897 "My.Yahoo - Logs you out when using Back button" ... but i could be wrong.

i could not see this bug on some problematic pages anymore. Marking VERIFIED FIXED. Well done :-)

As mentioned in comment 35, trying to read any story off www.nytimes.com results in this Redirection Limit Exceeded error. This is still 100% reproducible for me on Mac OS X, build 2002-03-21-03. Please reopen.

Just to tie up loose ends... I did some more searching and found out that the redirection limit problem is related to the profile. I created a new profile with a build from after this landed and the problem is gone.