Closed Bug 127348 Opened 22 years ago Closed 22 years ago

Redirection limit for this URL exceeded


(Core :: Networking: HTTP, defect)

Not set





(Reporter: jens-uwe, Assigned: badami)





(7 files, 1 obsolete file)

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, 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

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

I saw several other website with this behaviour (eg., 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
Summary: Redirection limit for this URL exceeded → Redirection limit for this URL exceeded
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:

it should redirect to :

but mozilla fails ...
BTW: I accept all cookies
-> badami for investigation
Assignee: darin → badami
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:
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:

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
vinay: yes, that code is for offline support.
Need help in getting this reproduced.
Keywords: qawanted
I see this at too on Windows 2000 build 2002022308
(the site works OK in, dare I say it, IE6)
set NSPR_LOG_FILE=http.log

Repeat ur experiment. Attach http.log to this bug report once the problem happens.
Attached file logfile as badami wanted (obsolete) —
here is a logfile. 
as I described above, the problem always shows at my computer at work (compiled
binary from but not at the computer at home (self compiled from
csv). I don't know, if there are other differences...
U think that in

        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.
I clreared the cache via edit->preferences->advanced->cache and remade the
logfile. I hope it helps to find the problem.
Attachment #71651 - Attachment is obsolete: true
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.


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:
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.
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]

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.
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!
Attached patch patch to testSplinter Review
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.
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
what I thought after seeing the log:

1024[809e330]: http request [
1024[809e330]:   GET /sess/utn153c7eb0e461a8b/ HTTP/1.1
1024[809e330]:   Host:
1024[809e330]:   User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+)
1024[809e330]:   Accept:
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:
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:]
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
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:
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.

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

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:


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

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.


If I repeat the get, adding on the ?sn=xxxxxx
 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

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 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 and the problem shows up
there.  I tried the problem URL 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 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 works just fine in
IE6.  Bizarre.

Revisiting 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  I don't have a snoop when it was trying
to access before it started working :-(.  The badami
site works fine for me.  I will snoop again if I find another site that doesn't

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:-
- 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,
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. 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 
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

Attachment #74310 - Flags: superreview+
Comment on attachment 74310 [details] [diff] [review]
doom cache entry if redirecting back to self

Attachment #74310 - Flags: review+
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.

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
Attachment #74310 - Flags: approval+
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
new revision: 1.100; previous revision: 1.99
Closed: 22 years ago
Resolution: --- → FIXED
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=">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  I've been unable to login using "secure" mode
when starting at accepts my username and
password but dumps me back at 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, then going to groups.

The latest build allows me to successfully login at
using the secure mode.

I did a few searches in bugzilla, but I don't see any likely
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 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.
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.