Hi Kelson, On Mon, Oct 18, 2004 at 04:39:34PM -0700, Kelson Vibber wrote:
I was attempting to pull up the bug database for Wordpress <http://mosquito.wordpress.org/> in Dillo 0.8.3rc2, and noticed that the browser froze when I clicked on the "View bugs" link. After I killed it and re-launched it from a command line, I saw it spewing Nav_open_url messages over and over, alternating between these two lines:
Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_bug_page.php<; Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_set.php?type=0<;
Yes, it happens...
I'm not entirely sure what the site is trying to do, but Firefox, Opera and IE all seem to make it through okay. I suspect it's something like this:
1. view_all_bug_page.php checks for a cookie. It doesn't find it, so it redirects (302) to view_all_set.php?type=0 2. view_all_set.php sets the cookie, then sends the browser back to the original page. 3. Either Dillo hasn't accepted the cookie and view_all_bug_page.php sends the redirect again, or Dillo has already cached the 302 response and jumps to view_all_set.php anyway.
Adding mosquito.wordpress.org to cookiesrc doesn't make a difference.
Currently Dillo's cache is handling HTTP 30x answers as cacheable redirections. This is more a lack of implementation than a BUG (there's no code to handle 302 answers now).
Based on the libwww-perl HEAD utility (which breaks out of the loop after 7 redirects) and just telnetting to port 80, I've found the following:
- They're using a 302 (temporary) redirect on both scripts - They're setting a cookie on view_all_set.php. - They're using relative URLs in the Location header (which I think is technically not allowed, but has been used in practice for years.)
Dillo handles relative locations.
Regardless of whether this setup is valid, it *does* make Dillo stop responding. There is at least one bug here -- Dillo isn't detecting the redirect loop and breaking out of it -- and possibly two (if it's caching the 302/temporary status).
Yes, there're two problems. Dillo hogging the CPU is a BUG that'd be better fixed for 0.8.3. The caching problem is a large issue that needs much more time to tackle. The cache problem is very interesting: if a browser happens to follow the SPEC, it becomes easy to abuse (e.g. pragma: no-cache advertising). OTOH, some sites can require to refresh some page contents in order to keep some meaningful state (HTTPS services usually use cache directives). Maybe as it happens with cookies, just allowing certain cites and honoring HTTP cache directives from that set only, is a good solution in the long term. I'll try to find a way to catch the redirection loop hog... -- Cheers Jorge.-