115252 - going to http://orange.dk produces redirection error

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Henrik Gemal]

entering besked.dk into the location bar and hitting enter produces:
"Redirection limit for this URL exceeded. Loading aborted."

Hitting enter aging in the location field loads the page.

build 20011213

Comment 1

[tenthumbs]

http://besked.de/ redirected me to http://myorange.dk/besked/ which 
redirected me to 
http://myorange.dk/besked/?sid=$$rgnEh42YVhkNhOkYzr88UFGF$$&map_cookie_check=1 
which then redirected me back to http://myorange.dk/besked/ after 
setting some cookies.

It wouldn't surprise me if some combination of mozilla's cookie or other 
settings made this site loop.

Comment 2

[Darin Fisher]

using the 2001121408 linux build, i had no problem visiting this site.

we might want to increase the redirection limit from 10 to 20 thereby greatly
increasing the likelihood that the redirection error results from a true
infinite redirection loop. 

Comment 3

[Matthias Versen [:Matti]]

I get this error on win2k with an 4h old CVS build.
Is there something wrong on win32 ?

Comment 4

[Darin Fisher]

possibly... this may depend on your cookie settings, etc.  

matti: can you try a new profile?

Comment 5

[Matthias Versen [:Matti]]

It the same with a new profile.

only one email per bug change needed : I'm watching you :-)

Comment 6

[Darin Fisher]

ok thx for the quick feedback :)

Comment 7

[Darin Fisher]

-> vinay

Comment 8

[Matthias Versen [:Matti]]

It works now for me with an 10min old CVS build (updated)

Comment 9

[tenthumbs]

I don't see why increasing the limit does any good. Either
  a) the site is looping on its own, or
  b) some cookie/js/whatever setting is making it loop, or
  c) mozilla is strangely broken.

In the first two cases, looping will still occur no matter what the 
limit. In the last, you don't want to cover up a bug, do you? :-)

Comment 10

[Vinay Badami]

Works for me.

Reporter, can u please check with the latest build ?

Comment 11

[Vinay Badami]

This one works for me. Please reopne if it does not work with the latest moz builds.

Comment 12

[Henrik Gemal]

just got the error using 20011231 on Win2k

Comment 13

[Ric Steinberger]

If anyone's keeping score, the bug is still present when clicking on
www.nytimes.com links in version 2002010203.

Comment 14

[Sean Harding]

I've been getting this error on nytimes.com as well (build 2002010308 at the
moment). Very annoying. Clicking on the link the second time usually loads it.

Comment 15

[Vinay Badami]

Darin 
does the 
set NSPR_LOG_MODULES=nsHttp:2 
allow for logging of the http request/response part on optimized bits also ?

If so we can ask these people to try it since I'am not able to reproduce it for
whatever reason.

Comment 16

[Henrik Gemal]

couldn't reproduce it on besked.dk today but on orange.dk.
to reproduce:
1) exit mozilla
2) launch mozilla
3) enter into the Location field orange.dk and hit enter. you'll get the error. 

I'll attach my http log done with set NSPR_LOG_MODULES=nsHttp:2

Comment 17

[Henrik Gemal]

Attachment: http log

Comment 18

[Sean Harding]

Here's another one that does it:

http://www.bell.ca/shop/application/commercewf?origin=*.jsp&event=link(productDetail)&wlcs_catalog_item_sku=58303

Comment 19

[Sean Harding]

Actually, I half take that back. The bell.ca site has some really bizarre
behavior that could legitimately be considered redirect looping. 

HOWEVER, mozilla only allows one redirect if it appears to be pointing back to
itself (i.e. the URI in the Location header is the same as the current
location). I made this sample script to demonstrate:

http://ophelia.dogcow.org/cgi-bin/doredir.cgi

This script checks for the presence and value of a cookie and if it isn't set
(or is set to the wrong thing), it sets the cookie and redirects back to itself.
If the cookie is set and has the right value, it shows the page. This works fine
in IE -- the cookie gets set, the browser loads the page again and gets the
data. In Navigator 4, it still works but not as cleanly -- I get a page that
says "Found   The document has moved here" with a link back to the page. But
mozilla doesn't let me get to the page at all. It just pops the "redirection
limit exceeded" error. 

It seems that at the very least, it should use the Nav 4.x behavior of giving a
link to the page. But it doesn't really seem any more dangerous to just allow 10
redirects in this case also. If it really is an infinite loop, it'll be stopped
as effectively as it would if the URLs weren't the same. And if it's not, the
user experience is a lot nicer. 
   

Comment 20

[Vinay Badami]

This bug happens because when we process a 302 we are caching the response.
Hence we keep redirecting to the same site over and over again.
The HTTP/1.1 spec says the following in section 10.3.3
 The requested resource resides temporarily under a different URI. Since the
redirection might be altered on occasion, the client SHOULD continue to use the
Request-URI for future requests. This response is only cacheable if indicated by
a Cache-Control or Expires header field.

All testing against the test cgi at http://ophelia.dogcow.org/cgi-bin/doredir.cgi


I do agree that 
http://www.bell.ca/shop/application/commercewf?origin=*.jsp&event=link(productDetail)&wlcs_catalog_item_sku=58303
is flawed and seems to be redirecting to itself. This is an invalid url and we
are correctly detecting the looping in this case.

Comment 21

[Vinay Badami]

Attachment: Do not cache results for a 302 unless the response tells u to

1. nsHttpChannel.cpp
Separate case for 302 which first checks if the response can be cached as per
the spec. 
2. nsHttpResponseHead.[cpp,h]
Added new method PRBool nsHttpResponseHead::IsCacheable(PRInt32 httpStatus)
Broke up PRBool nsHttpResponseHead::MustRevalidate() into two parts to enable
code reuse from IsCacheable.

An alternative is to not cache any 302 responses at all.This may also just work
out fine.

Comment 22

[Darin Fisher]

i talked to vinay via AIM about this bug... 302's are supposed to be cached for
the purposes of offline browsing.  however, unless the server specifies cache
control headers that permit reuse, the cached 302 redirects should never be used
to satisfy normal online http requests.  the real bug here seems to be that the
cached 302's are being used when the site says that they should not.

Comment 23

[Vinay Badami]

Here is what is going on

request url was for 
http://ophelia.dogcow.org/cgi-bin/doredir.cgi

Send back a 302 with a cookie and location header being the same as the original
uri.

Response gets into cache with expiration time being now + timeRemaining.
Note that now is timeInSecs and timeRemaining is 0.

The 302 triggers a redirect which finds the response in the cache. The access
for the cache entry  is 3 (READ_WRITE). Since we do time in seconds, the check
for expired time in nsHttpChannel::CheckCache()
if (NowInSeconds() <= time) 
succeeds. 

This reults in triggerring of another redirect which again finds the cache entry
but with access being READ_ONLY. Hence this now exits CheckCache as a result of
the following    // If we were only granted read access, then assume the entry
is valid.
    if (mCacheAccess == nsICache::ACCESS_READ) {
        LOG(("nsHTTPChannel::CheckCache returning because we have only read
access mCachedContentIsValid is 1"));
        mCachedContentIsValid = PR_TRUE;
        return NS_OK;
    }

This now continues until the redirection limit is reached.

1. Is it that offline browsing mode required this check for (mCacheAccess ==
nsICache::ACCESS_READ) ?
2. Is so then should we AND that condition with this check ? Is that the only
case that this would be true ?
3. Would it suffice to correct the IsCacheable logic in my previous patch adding
to it the caching logic ?


 

Comment 24

[Vinay Badami]

Attachment: trace of the cache behaviour

Attaching a trace of debug messages from running mozilla with the logging at
level 5.
Search in this attachment for got cache entry . Note that access =
3(READ_WRITE) only the first time and is 1 (READ_ONLY) subsequently.

Also search for the string "nsHTTPChannel::CheckCache returning because we have
only read access". Note that this happens on whenever we get acces a READ_ONLY.

Comment 25

[Darin Fisher]

vinay: good work collecting information on this.  one simple solution to this
bug might be to modify the logic in UpdateExpirationTime.  in the case of a zero
freshnessLifetime, we could set an expiration time equal to zero instead of now
+ timeRemaining.  i think this is better than trying to rework the CheckCache
logic... since the cache entry's expiration time is essentially a parameter to
CheckCache.

Comment 26

[Vinay Badami]

Attachment: based on darins comments

If timeremaining is 0, set expiration time to 0.

Comment 27

[Darin Fisher]

i think it might be better to ignore currentAge if freshnessLifetime is zero.  
i say this because you could have a 302 response with a non-zero currentAge...
that might result from a slow connection, and you would still want to force a
zero expiration time.

Comment 28

[Vinay Badami]

Darin
Are the early returns from UpdateExpirationTime on NS_FAILURE by intent ? I mean
to point out that in these cases, we exit without updating the expiration time
on the cache. Should we be setting it the expirtion time on the cache entry to 0
in these cases ?

I would like to modify the code to read as follows. However, with this change
the behavior on failure cases changes. I'am not sure if the early returns were
intentional or otherwise.

nsresult
nsHttpChannel::UpdateExpirationTime()
{
    PRUint32 now = NowInSeconds(), timeRemaining = 0, expirationTime = 0;

    NS_ENSURE_TRUE(mResponseHead, NS_ERROR_FAILURE);

    if (!mResponseHead->MustRevalidate()) {
        nsresult rv;
        PRUint32 freshnessLifetime = 0, currentAge = 0;

        rv = mResponseHead->ComputeFreshnessLifetime(&freshnessLifetime);
        if (NS_SUCCEEDED(rv) && (freshnessLifetime > 0)) {
            rv = mResponseHead->ComputeCurrentAge(now, mRequestTime,&currentAge); 
            if (NS_SUCCEEDED(rv)) {
                LOG(("freshnessLifetime = %u, currentAge = %u\n",
                        freshnessLifetime, currentAge));
                if (freshnessLifetime > currentAge) {
                    timeRemaining = freshnessLifetime - currentAge;
                    if (timeRemaining > 0)
                        expirationTime = now + timeRemaining;
                }
            }
        }
    }

    return mCacheEntry->SetExpirationTime(expirationTime);
}

Comment 29

[Darin Fisher]

the early returns were okay because they would have resulted in canceling of the
channel and therefore dooming of the cache entry.  in other words, those errors
can be thought of as exceptions.

also, there is no reason to check if timeRemaining > 0... it always will be.
if you remove this check, then timeRemaining can also go away... instead you'd
have expirationTime = now + freshnessLifetime - currentAge.

the declaration/assignment of now should probably also be moved inside the
MustRevalidate if block.

BTW: MustRevalidate is now MustValidate... that is the change i mentioned to you
yesterday that would break this patch.

Comment 30

[Ric Steinberger]

I'm not up enough on the HTTP specs to know whose fault this bug actually is. 
But  I certainly hope that some kind of fix, override option or workaround is
included in the 0.9.8 version.  When a site like www.nytimes.com has links that
cannot be accessed without bumping into this error, there is a real problem for
end users.

Comment 31

[Darin Fisher]

ric: no worries... the fix is definitely in hand.

Comment 32

[Vinay Badami]

Attachment: one more

1. Return back failure status if there was a failure. Earlier patch would have
returned wrong status from the function.
2. Got rid of timeRemaining.
3. Moved declaration of now into inner block.
4. The only difference between the previous code and the current one would be
that we set expiration time of cache entry to 0 on failure. This should be ok
in y opinion. Darin, can u confirm please ?

The http://ophelia.dogcow.org/cgi-bin/doredir.cgiworks with this patch.

Comment 33

[Darin Fisher]

Comment on attachment 64473 [details] [diff] [review]
one more

returning immediately on NS_FAILED(rv) would simplify your patch quite a bit...
for example, it would eliminate the need for temprv and eliminate at least one
level of nesting.  i suggest that you rewrite the patch to return on failure
immediately instead.

Comment 34

[Vinay Badami]

Attachment: with the earlt returns

Comment 35

[Darin Fisher]

there is a subtle error in this patch that i just caught.  it turns out that a 0
expiration time actually translates to an infinite expiration time as far as the
cache is concerned.  even though HTTP sets the "doom-if-expired" cache flag to
false, the memory cache will still use the expiration time in its eviction
ranking, so we need to NOT set an expiration time of zero.  for the purposes of
this patch, a value of 1 would suffice.  (i've filed bug 120833 to get the sense
of an expiration time of zero reversed.)

Comment 36

[Darin Fisher]

Attachment: revised patch to use a minimum expiration time of 1 instead of 0, and removed unused variable

Comment 37

[Darin Fisher]

Attachment: revised per comments from gordon (fixed a potential overflow bug)

Comment 38

[Scott MacGregor]

Comment on attachment 65673 [details] [diff] [review]
revised per comments from gordon (fixed a potential overflow bug)

sr=mscott

Comment 39

[Christopher Blizzard (:blizzard)]

Comment on attachment 65673 [details] [diff] [review]
revised per comments from gordon (fixed a potential overflow bug)

r=blizzard

Comment 40

[Darin Fisher]

got an r=gordon as well... so a=blizzard?

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 65673 [details] [diff] [review]
revised per comments from gordon (fixed a potential overflow bug)

a=dbaron for 0.9.8

Comment 42

[Darin Fisher]

fixed-on-trunk

Comment 43

[Darin Fisher]

*** Bug 119716 has been marked as a duplicate of this bug. ***

Comment 44

[Andrew Hagen]

*** Bug 121128 has been marked as a duplicate of this bug. ***

Comment 45

[Tom Everingham]

verified: 01/25/02 trunk builds -  win NT4, linux rh6, mac osX

Comment 46

[Ric Steinberger]

This is still a bug.  I have downloaded build 2002011103, and visit the
www.nytimes.com web site.  [You need to register to be able to get past the main
page.]  Click on any link on the main page, and there's that redirection limit
error.  In other words, I see no change from the original bug, at least at the
NY Times site.

Comment 47

[John Morrison]

> ... downloaded build 2002011103 ...

... and since the fix landed on the trunk on 20020119, one shouldn't expect to 
see it fixed in builds prior to that date. 

For what it's worth, I am not seeing the redirection limit error on the 
nytimes.com site with current builds.

Comment 48

[Tom Everingham]

yeah this was easily reproducable at various sites.  It's working now.

Comment 49

[Ric Steinberger]

I just downloaded (25 jan 2002, 17:00 PST) version 2002102503, on Windows 2000,
SP2.  I am definitely still seeing the Redirection error, at the www.nytimes.com
site.  I'll shut up if you guys think this is fixed, but I'm still seeing a
problem on my system.  If anyone's interested, I could try some experiments.

Comment 50

[Matthias Versen [:Matti]]

[e-mail]: 
Have you downloaded a trunk or branch build ?

Comment 51

[Darin Fisher]

ric: check "help->about mozilla" for the useragent string... it'll tell you if
you are using a trunk or branch build.  thx!

Comment 52

[Matthias Versen [:Matti]]

*** Bug 121818 has been marked as a duplicate of this bug. ***

Comment 53

[Ric Cefis]

I've downloaded a recent nightly
(ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-01-27-11-trunk/mozilla-win32-installer-sea.exe)

It identifies itself as:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020127

Given the path, I assume this is a trunk build, and so the bug should be
resolved for my installation. However, the bug still manifests itself at various
sites I visit, particularly:

www.nytimes.com
www.techdata.ca (and .com too)

Not sure why this is happening...I once commented on this bug in n.p.m.general
newsgroup (Oct 2001 or earlier), but after downloading newer builds, the problem
disappeared. It reappeared early Jan 2002, but I haven't a clue why.

Hope this helps.

BTW: if you need to contact me, do so at [e-mail]; the email address
listed for my bugzilla account no longer exists (how can I change it? should I
email someone?)

Comment 54

[Ric Cefis]

*ahem*

Let me try again...

I downloaded the installer
(ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-01-27-08-0.9.8/mozilla-win32-installer-sea.exe)

which identifies itself as:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8) Gecko/20020127

With my old profile, I still see the redirection limit problem. When I created a
new profile, the problem is solved for every site I visit for which this problem
existed.

Why should profiles make such a difference? (Old profile was created with one of
0.6 or 0.8.0 release, new profile created with the build from link listed in
this comment)

Glad to see this works though!

Comment 55

[Vinay Badami]

Can u mail me a http log ? Please refer to comment #15 for the specifics.

Comment 56

[Darin Fisher]

i think i know what's going on.  before the patch for this bug landed, we were
computing expiration times relative to the response time + some non-negative
delta.  these expiration times were being written to the disk cache.  patched
builds OTOH set a zero expiration time for entries that should not be cached for
normal page loads.  my guess is that your old profile contains some of the older
entries w/ expiration times sufficiently in the future relative to your system
clock. this would cause mozilla to reuse the cached redirects over and over and
over again until reaching the limit on the number of redirects.

if you can run about:cache using your old profile and look at all the entires
pertaining to nytimes.com or supply the http log as vinay requested that might
enable us to determine what went wrong with your old profile.  thx!

Comment 57

[Darin Fisher]

marking FIXED

Comment 58

[Ric Cefis]

Darin,

I tried about:cache, and there were *no* entries for nytimes.com (I purge the
cache, but infrequently). Even under this scenario, the old profile gives the
redirection error.

I'm not that concerned about my old profile - I've created a new one and
migrated my settings from the old one, and I plan on doing so again when 1.0 is
released. I just thought I'd report the behaviour for the sake of completeness. 

I don't have any problems associated with this bug with the new profile.

As for the http log, I assume the instructions (given in comment 15) are for
individuals who create their own builds (?) - I don't currently have the tools
to do so.

I installed a web proxy to test; I'll put the results in another comment.

Comment 59

[Ric Cefis]

Here's the http log from the web proxy. I did the following:

1. Visit www.nytimes.com homepage
2. Select a link
(http://www.nytimes.com/reuters/international/international-mideast.html)

The last six lines of the log represent the link I followed that caused the
redirection limit error. All other lines were from step 1. 

format=%Ses->client.ip% - %Req->vars.pauth-user% [%SYSDATE%]
"%Req->reqpb.proxy-request%" %Req->srvhdrs.clf-status% %Req->vars.p2c-cl%
%Req->vars.remote-status% %Req->vars.r2p-cl% %Req->headers.content-length%
%Req->vars.p2r-cl% %Req->vars.c2p-hl% %Req->vars.p2c-hl% %Req->vars.p2r-hl%
%Req->vars.r2p-hl% %Req->vars.xfer-time% %Req->vars.actual-route%
%Req->vars.cli-status% %Req->vars.svr-status% %Req->vars.cch-status%
[myIP] - - [31/Jan/2002:17:02:19 -0500] "GET http://www.nytimes.com/ " 200 0 200
59216 0 0 0 176 661 176 9 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:19 -0500] "GET
http://www.nytimes.com/js/csssniff.js " 304 0 304 0 0 0 0 120 787 120 2 DIRECT
FIN FIN -
[myIP] - - [31/Jan/2002:17:02:20 -0500] "GET http://www.nytimes.com/css/sft1.css
" 304 0 304 0 0 0 0 120 786 120 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:21 -0500] "GET
http://graphics4.nytimes.com/images/misc/spacer.gif " 304 0 304 0 0 0 0 239 717
239 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:21 -0500] "GET
http://graphics4.nytimes.com/RealMedia/ads/Creatives/nytnytHP/96X60_EE-orange.gif
" 304 0 304 0 0 0 0 254 717 254 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:21 -0500] "GET
http://graphics4.nytimes.com/images/section/homepage/NYT_home_banner.gif " 304 0
304 0 0 0 0 239 717 239 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:22 -0500] "GET
http://graphics4.nytimes.com/RealMedia/ads/Creatives/tiffan12/nyt_val.jpg " 304
0 304 0 0 0 0 264 760 264 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:22 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/classifieds/jobs.gif " 304
0 304 0 0 0 0 239 717 239 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:22 -0500] "GET
http://amch.questionmarket.com/adsc/d96342/1/96438/randm.js " 200 505 200 505
505 0 0 331 653 331 1 DIRECT FIN FIN CREATED
[myIP] - - [31/Jan/2002:17:02:22 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/classifieds/realestate.gif
" 304 0 304 0 0 0 0 247 717 247 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:23 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/classifieds/automobiles.gif
" 304 0 304 0 0 0 0 247 717 247 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:23 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/gn_news.gif " 304 0 304 0
0 0 0 239 717 239 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:23 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/gn_features.gif " 304 0
304 0 0 0 0 247 717 247 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:23 -0500] "GET
http://graphics4.nytimes.com/images/global/global_nav/gn_newspaper.gif " 304 0
304 0 0 0 0 263 717 263 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:24 -0500] "GET
http://graphics4.nytimes.com/ads/vail/vailbigdeal86x40.gif " 304 0 304 0 0 0 0
272 717 272 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:24 -0500] "GET
http://graphics4.nytimes.com/ads/gap/gapmaternity2.gif " 304 0 304 0 0 0 0 247
717 247 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:24 -0500] "GET
http://graphics4.nytimes.com/ads/juno_mktplce.gif " 304 0 304 0 0 0 0 263 717
263 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:24 -0500] "GET
http://graphics4.nytimes.com/ads/british/86x40_2k.gif " 304 0 304 0 0 0 0 263
717 263 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:25 -0500] "GET
http://graphics4.nytimes.com/ads/half/86x40box.gif " 304 0 304 0 0 0 0 239 717
239 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:25 -0500] "GET
http://graphics4.nytimes.com/images/global/global_search/gs_search.gif " 304 0
304 0 0 0 0 295 717 295 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:25 -0500] "GET
http://graphics4.nytimes.com/ads/starbucks.gif " 304 0 304 0 0 0 0 239 717 239 1
DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:25 -0500] "GET
http://graphics4.nytimes.com/images/2002/01/31/international/31cnd-fight.1.jpg "
200 6129 200 6129 6129 0 0 261 675 261 0 DIRECT FIN FIN CREATED
[myIP] - - [31/Jan/2002:17:02:25 -0500] "GET
http://graphics.nytimes.com/images/promos/homepage/29duck-overlay.gif " 304 0
304 0 0 0 0 110 750 110 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:26 -0500] "GET
http://graphics.nytimes.com/images/promos/homepage/31tali-overlay.gif " 304 0
304 0 0 0 0 110 750 110 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:26 -0500] "GET
http://graphics.nytimes.com/images/misc/spacer.gif " 304 0 304 0 0 0 0 101 716
101 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:26 -0500] "GET
http://graphics.nytimes.com/images/misc/formArrow2.gif " 304 0 304 0 0 0 0 101
716 101 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:26 -0500] "GET
http://graphics4.nytimes.com/images/section/c_markets.gif " 304 0 304 0 0 0 0
272 717 272 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:26 -0500] "GET
http://graphics4.nytimes.com/images/2001/11/05/wall_st_60x60.gif " 304 0 304 0 0
0 0 296 717 296 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:27 -0500] "GET
http://graphics4.nytimes.com/images/promos/homepage/19pog-banner.gif " 304 0 304
0 0 0 0 263 717 263 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:27 -0500] "GET
http://graphics4.nytimes.com/images/2002/01/27/sports/27POGblackwell.1.gif " 304
0 304 0 0 0 0 239 717 239 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:27 -0500] "GET
http://graphics4.nytimes.com/images/section/homepage/cat_wire.gif " 304 0 304 0
0 0 0 247 717 247 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:27 -0500] "GET
http://graphics4.nytimes.com/images/section/homepage/cat_abuzz.gif " 304 0 304 0
0 0 0 247 717 247 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:27 -0500] "GET
http://graphics4.nytimes.com/RealMedia/ads/Creatives/strade11-nyt1/ODDSIZE487.gif
" 304 0 304 0 0 0 0 263 717 263 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:52 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 669 288 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:54 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 695 288 2 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:55 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 695 288 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:56 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 695 288 0 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:57 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 695 288 1 DIRECT FIN FIN -
[myIP] - - [31/Jan/2002:17:02:57 -0500] "GET
http://www.nytimes.com/reuters/international/international-mideast.html " 302 0
302 0 0 0 0 288 695 288 0 DIRECT FIN FIN -


I assume the 302 refer to the redirects...is this info specific enough?

I'll mention again that my new profile does not exhibit this problem; I only
submit this information in the event that it may be useful in the future.

Comment 60

[Boris Zbarsky [:bzbarsky]]

*** Bug 122827 has been marked as a duplicate of this bug. ***

Comment 61

[Darin Fisher]

ric: actually the instructions in comment #15 apply to _all_ mozilla builds. 
vender specific builds may have logging disabled, but by default mozilla builds
have this enabled for the purpose of helping bug reporters submit more useful
bug reports ;-)

Comment 62

[Darin Fisher]

ric: thanks for the proxy server output, but it really doesn't tell me much.  it
only confirms that redirects are happening repeatedly.

Comment 63

[John Morrison]

(side comment: ... but the proxy logs do tell us that the bug is ~different 
from the situation previously noted with nytimes.com and cookie-validation, 
in that the previous situation (detailed in bug 119716) would have generated 
a request for    
    http://www.nytimes.com/whatever...
which would redirect to 
    http://www.nytimes.com/auth/login?URI=http://www.nytimes.com/whatever...
and then loop between the above two URLs.

The above proxy log shows that it is only looping on a single 302 URL

Comment 64

[John Morrison]

Actually, sorry ... this may not be different, since it's not clear which 
requests were serviced internally by the disk cache (unheard by the proxy 
server) and which requests were actually serviced by the proxy server.

Comment 65

[Darin Fisher]

jrgm: exactly.  but, also there is little distinction in the code between
redirecting to the same URL and redirecting between two different URLs.  they
follow identical code paths at the networking/cache level.

Comment 66

[Ric Steinberger]

wah!  Just downloaded 0.9.8 and visited http://www.nytimes.com.  This bug is
still present on my Windows 2000 system.  

I can send further information, but I would need explicit directions on what is
needed and how to get it.  [I'm a network security techie... so I'm not familiar
with the ins and outs of Mozilla logging/debugging.]

Comment 67

[Matthias Versen [:Matti]]

it seems that this is only fixed in the trunk builds:
fixed-on-trunk (comment #42) and that means that 0.9.8 doesn't have this bug fix..

Comment 68

[Darin Fisher]

matti: actually, this bug should have been fixed in mozilla 0.9.8... the branch
wasn't cut until after the patch landed.

ric: try this: try a new profile... that might fix the problem.  maybe.

Comment 69

[Ric Steinberger]

Good grief!  Creating a new profile seems to have removed the problem, at least
as I was seeing it on the www.nytimes.com site.  Can someone explain that?

Comment 70

[Andrew Hagen]

The corruptability of profiles may be a bug. See bug 123027 for some current work.

Comment 71

[Darin Fisher]

ric: see comment #56

Comment 72

[Quinn Yost (mythdraug)]

*** Bug 125657 has been marked as a duplicate of this bug. ***

Comment 73

[Henrik Gemal]

v 20020221

Comment 74

[neeti]

*** Bug 114703 has been marked as a duplicate of this bug. ***

Comment 75

[alanjstr]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020714

I'm having problems with nytimes.com.  Following the chain of bugs, its's
pointed me to here.  I recommend re-opening.

http://www.nytimes.com/2002/07/14/national/14PILO.html?todaysheadlines

Comment 76

[John Morrison]

I regularly go the nytimes.com, and I haven't been having a problem
with current trunk builds. However, if you are experiencing a problem,
can you open a command shell, enter these commands (for win32 or *nix
tcsh) and then start mozilla from that command line. The output in
'http.log' would be useful.

set NSPR_LOG_MODULES=nsHttp:5
set NSPR_LOG_FILE=http.log