114709 - Redirection Limit error.

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect)

Description

[Stephane Saux]

Build ID: 2001121003
Start moz.
go to http://www.nytimes.com
click on a story link, you get the redirection limit error dialog.
Dismiss the dialog,
click on the link again. 
Page loads.

Comment 1

[Boris Zbarsky [:bzbarsky]]

networking.  Happens on Linux too.

Comment 2

[Darin Fisher]

ssaux: can you try adjusting the pref:

user_pref("network.http.redirection-limit", 10);

from 10 to something larger and see if this problem goes away?

perhaps we need to make the default for this something larger... or perhaps this
indicates some infinite redirect case on nytimes.com.

thx!

Comment 3

[tenthumbs]

FWIW, I cannot reproduce this with a 12-11 nightly. Looking through a 
packet dump I can't find any loops either.

I would say this shows why including the URL in the error message is 
a good idea.

Comment 4

[Stephane Saux]

I tried a few things, but couldn't reproduce.
I'll let you know if it occurs again.

Comment 5

[Chris Underhill]

I can reproduce this by visiting https://www.mybroker.co.uk using both 0.9.6 and
build 2001121308-trunk on Linux (Red Hat 7.1 + updates). The problem appears to
be cookie related and in particular, the "Limit maximum lifetime of cookies" 
option in the cookies section of the privacy & security preferences.

Normally I have this option checked and select "current session". If you log in
to the site mentioned with a bogus username & password ('foo' & 'bar' for
instance) it overwrites the (initial) session cookies with new values and a new
expiry date from 1970, and so they should be junked. With the builds mentioned
of Mozilla, the page gets reloaded several times and then if after getting the
"redirection limit exceeded" dialog you view the stored cookies, you'll see that
they are still there and are scheduled to expire at the end of the current session. 

It appears therefore they get (wrongly) presented again to the site when the
failed logon page is retrieved, but as the site uses the cookies to identify the
user and these cookies are bogus, you get immediately redirected again to the
failed logon page. This cycle repeats for ever until the redirection limit
exceeded message pops up.

Fix should be for the cookies to always be junked if they have an expiry date in
the past regardless of the settings in cookie preferences.

Comment 6

[Darin Fisher]

-> cookies

Comment 7

[Stephen P. Morse]

Chris Underhill, thanks for doing the analysis on this.  You are absolutely 
correct -- the problem is being caused by limiting expired cookies to session 
cookie, thereby inadvertantly extending rather than limiting their lifetimes.

Same problem will occur with p3p when it tries to downgrade a cookie to a 
session cookie -- therefore it needs to test for expired cookies before doing 
such downgrading.

Attaching patch that fixes problems.

Comment 8

[Stephen P. Morse]

Attachment: test for expired cookie before downgrading to session cookie

Comment 9

[Stephen P. Morse]

cc'ing alecf and sgehani for reviews.

Comment 10

[Alec Flett]

Comment on attachment 61887 [details] [diff] [review]
test for expired cookie before downgrading to session cookie

add some comments to the c++ (the JS ones explaint this well) and sr=alecf

Comment 11

[Chris Underhill]

An additional thought - some sites use cookies with an expiry date of just a few
minutes in the future as a method of forcing (normal!) users to login again if
they have been idle for too long. AFAICT, if the preferences are set to convert
cookies to all be session cookies, this will no longer work: The "expires in n
minutes" will be "downgraded" to expires at end of session, which, as Mozilla is
now very reliable, could well be more than n minutes in the future. 

A better solution imo would be to process/expire such (downgraded) cookies as
normal but simply do not write them to the cookie file, so they that they are
unknown to subsequent sessions but do expire correctly.

Comment 12

[Stephen P. Morse]

Yes, you are correct in that cookies set to expire in the "very near future" 
will instead be "upgraded" to live for the entire session.  But that's much less 
serious than the current problem, so I suggest you open a separate bug report on 
it.  Reference this bug number in that report.

Comment 13

[Samir Gehani]

Comment on attachment 61887 [details] [diff] [review]
test for expired cookie before downgrading to session cookie

r=sgehani

Comment 14

[Stephen P. Morse]

Patch checked in.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Grey Hodge (jX)]

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

Comment 18

[John Morrison]

The fix in this bug perhaps applied to https://www.mybroker.co.uk, but 
did not apply to http://www.nytimes.com/ (see bug 119716). Since the three 
dups above were all for nytimes.com, I'm changing the URL for this bug to 
point to https://www.mybroker.co.uk, and leaving bug 119716 for the nytimes.com 
situation.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Charles Bargar]

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

Comment 21

[benc]

V/fixed. Mac OS X, Mozilla 1.84a,
cookies in the past never appear in cookie manager.