Bug 153538 - Bogus "found a cyclic link" error on LiveJournal
Summary: Bogus "found a cyclic link" error on LiveJournal
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-06 07:35 UTC by Josh Berry
Modified: 2008-01-10 18:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
patch. (3.23 KB, patch)
2008-01-10 08:31 UTC, Maksim Orlovich
Details
better patch (3.80 KB, patch)
2008-01-10 18:34 UTC, Maksim Orlovich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Berry 2007-12-06 07:35:04 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 4.2 
OS:                Linux

KDE4 recent SVN:

When visiting a LiveJournal friend page (for example, http://deskitty.livejournal.com/friends ), Konqueror reports a cyclic link.

Every other web browser I've tested (including Konqi 3.5) seems fine with this page.
Comment 1 Maksim Orlovich 2007-12-06 16:03:20 UTC
Can't confirm... How recent is 'recent'?
Comment 2 Josh Berry 2007-12-06 17:36:08 UTC
A day or two.

You may need to be logged in to a LiveJournal account for it to break.  Next time I'm in a KDE4 session I'll do some experimentation to see.
Comment 3 Josh Berry 2007-12-09 03:18:46 UTC
I can't reproduce this anymore, either logged in or logged out.  Perhaps it got fixed very recently.  (I just updated a couple hours ago.)
Comment 4 Josh Berry 2008-01-05 08:00:45 UTC
This bug has reappeared.  (I last updated SVN within the past hour.)  You have to be logged in to LiveJournal, and visiting a user's page (e.g. http://deskitty.livejournal.com/ ).  It works fine if you are viewing a user's page as an anonymous user.
Comment 5 Germain Garand 2008-01-05 11:39:13 UTC
this happened to me once when I had a botched cookie daemon.
Check if it says something like "can't talk to cookie daemon" when you go to:
  Settings > Cookies

if so try launching kcookiejar4 and see if it fix things.
Comment 6 makosoft 2008-01-06 15:30:18 UTC
I'm suffering from the same issue with a day or so old copy of KDE4 svn trunk. The cookie daemon is definitely running - Settings > Cookies is showing up and cookies work on other sites.

I've taken a look at the requests with Wireshark. The user page 302 redirects to http://www.livejournal.com/misc/get_domain_session.bml, which then redirects to /__setdomsess on the subdomain with various parameters. This sets a "ljsession" session cookie for the subdomain and 302 redirects back to the original URL. However, the cookie doesn't seem to stick - the request for the original URL uses a non-session cookie with the same name set on ".livejournal.com" instead.

I suspect that, if you want to reproduce this, it may help to check "Remember me" when logging in to Livejournal.
Comment 7 Maksim Orlovich 2008-01-10 08:31:08 UTC
Created attachment 22929 [details]
patch.

Uff. This was hard. Had to go through kcookiejar, kio-http, khtml, kparts, and
finally kio proper to find it.

The problem is how KIO::SlaveBase::config() works... In 4.x, it's a normal
KConfig object which gets updated on handling of CMD_META_DATA and CMD_CONFIG.
The problem is that it removes old entries using mIncomingMetaData when new
ones come in, but that can be cleared in e.g. ::finished(). The attached clears
the config version in sync.

The actual failure scenario here was this:
1. Open livejournal.com... that sends a bunch of requests with cross-domain
annotation of livejournal.com in cross-domain metadata.
2. Open accountname.livejournal.com/friends via BrowserRun, which opens up 
a new job to try to get the mimetype.
3. The old slave, gets new metadata set, but by now it has forgotten it has
cross-domain set via metadata from the previous request, so the setting sticks
around. Cookies get handled with requirement of domain name www.livejournal.com
and not the accurate one. Big ouch, which the patch addresses.

That marks them as "Cross Domain" in cookie jar, which coincidentally can't
parse those at all, it skips over 1 too many chars in makeCookies, making
"Set-Cookie:" into "et-Cookie:". But that's a different bug, which I am not
ready to address, since I'd need to brush up on the policy here.. I recall some
BRs related to that, however.
Comment 8 Maksim Orlovich 2008-01-10 08:37:15 UTC
Ugh. I am not sure this is 100% correct, either, since presumably there can be overlap between metadata and config. We should probably just rebuild the entire thing, cascading them properly the way SlaveBase::metaData does.
That's what it pulled from in 3.x on demand, anyway. It's too late in the evening for me too touch this now, though... 

Comment 9 Josh Berry 2008-01-10 09:16:00 UTC
Wow, thank you so much for going to all the trouble of tracking this down.

Is the patch ready for testing?  If so, I'll apply it to my tree and see if it fixes the problem.
Comment 10 Maksim Orlovich 2008-01-10 18:34:10 UTC
Created attachment 22943 [details]
better patch

This should be better, and keep things fully in sync...

And to the reporter: bugs like these are part of the fun :-)
Comment 11 Maksim Orlovich 2008-01-10 18:53:31 UTC
SVN commit 759473 by orlovich:

Make sure that ->config() doesn't end up with stale metadata. Fixes e.g. 
infinite looping on LiveJournal friends page, and heaven knows what else.
BUG: 153538


 M  +24 -15    slavebase.cpp  
 M  +1 -0      slavebase.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=759473
Comment 12 Maksim Orlovich 2008-01-10 18:54:57 UTC
This is now in the 4.0 branch, and I'd definitely appreciate testing --- something else may be wrong, I feel, I've had some sporadic difficulties logging in, e.g.

(Not yet in 4.1/trunk branch..)