119716 - exceeding redirection limit, authenticating with www.nytimes.com

Status: VERIFIED DUPLICATE of bug 115252

(Core :: Networking: HTTP, defect)

Description

[John Morrison]

So, darin, I managed to reproduce that redirect bug I mentioned to you and
got an http.log of what's happening. I've put a copy of the log at
http://jrgm/bugs/nytimesRedirect/http.log. [Note: as it contains some cookie
information, I'd prefer that it not be made publically available].

Some notes: the log shows the browser startup and the loading of the default
home page http://www.mozilla.org/start.html. Then I typed
http://www.nytimes.com in the urlbar to load the main page of that
site. Finally, I clicked on one of the links on that page and received an
alert dialog saying that redirection limit had been exceeded.

The nytimes.com site has the front page available to anyone, but requires a
free user account to view the rest of the content on the site. For the
profile that I was using, I had previously logged into the site, but I had
not visited the site since at least last night. That's the key thing, and the
reason why it took a while to figure out how to reproduce.

The links of the main page of nytimes.com are "normal" URL. However, there
appears to be an auth handler that checks the age of the cookies. If they are
stale, a redirect is done to an URL which revalidates your user info and
redirects, setting fresh cookies. All this is (usually) transparent to the
end user (it's a standard ticket granting scheme).

What appears to happen in the log is that when I click on a link for:
  http://www.nytimes.com/2002/01/13/business/13SELL.html

I get a redirect to:
http://www.nytimes.com/auth/login?URI=http://www.nytimes.com/2002/01/13/business/13SELL.html
  

which then redirects back to:
  http://www.nytimes.com/2002/01/13/business/13SELL.html

At that point, I see a message in the log that says:
  "0[3244a0]: no mandatory validation requirement"
  "0[3244a0]: Not validating based on expiration time"
  "0[3244a0]: CheckCache [this=24451f0 doValidation=0]
  "0[3244a0]: nsHttpChannel::ReadFromCache [this=24451f0] Using cached copy of:
http://www.nytimes.com/2002/01/13/business/13SELL.html"


but that cache entry is a redirect to the auth URL:
  "0[3244a0]: no mandatory validation requirement
  "0[3244a0]: Not validating based on expiration time
  "0[3244a0]: CheckCache [this=24451f0 doValidation=0]
  "0[3244a0]: nsHttpChannel::ReadFromCache [this=24451f0] Using cached copy of:
http://www.nytimes.com/auth/login?URI=http://www.nytimes.com/2002/01/13/business/13SELL.html

and so, it bounces between these two URLs, decrement 'redirection-limit'
until it hits 0, and throws up the redirect alert.

I think all you need to do to reproduce this is to get a nytimes.com account
if you don't have one, log in, wait overnight, then (first saving a copy of
cookies.txt) start the browser fresh, load www.nytimes.com and click a link
on the main page.

Comment 1

[Matthias Versen [:Matti]]

John: Isn't this a dupe of  bug 114709 ?
I would know it you added a build ID :-)

Comment 2

[John Morrison]

Well, the condition fixed in bug 114709 never applied to nytimes.com, which 
uses only persistent cookies that are set 6 months to one year into the future.
As far as I can see, this has nothing directly to do with cookies, aside from 
the ticket granting scheme noted above, and it definitely has nothing to do 
with session cookies.

I think darin can see what's is happening from the http log, and the comments 
above. In addition, I have a reproducible profile and cookie settings saved 
elsewhere that can be used if darin can't reproduce this himself (or doesn't 
want to). 

I should have added the build id as you note: trunk build pulled 01/10 23:59
on win2k. 

Comment 3

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

All/All since this has been bugging me for weeks, on Linux, and I've been too
lazy to file a bug.  I see the message the first time I load an nytimes.com
article within a given browser session, and I have to click the link again.  (I
certainly think I've seen it twice in one day -- but I'll double-check.)

Comment 4

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

OK, I lied.  It's not every browser session.  But I think I've seen it twice in
the same day.

Comment 5

[Darin Fisher]

i think this may be a duplicate of bug 115252... which has a patch that should
be landing soon.  once it's in we can test out this bug and see if the problem
has been solved.

Comment 6

[Christopher Blizzard (:blizzard)]

I've seen this in classmates.com too.  Same symptoms as nytimes.

Comment 7

[Steve Peterson]

I've seen it >1 time a day.  Build 2002011703, Win2K SP 2.

Comment 8

[Darin Fisher]

bug 115252 has been fixed... marking this one as a duplicate.

*** This bug has been marked as a duplicate of 115252 ***

Comment 9

[Tom Everingham]

verified