On Mon, Oct 25, 2004 at 12:27:35AM -0700, Kelson Vibber wrote:

On Friday 22 October 2004 8:16 am, Jorge Arellano Cid wrote:

...

Please test it with sites that use cookies (as advogato) and with pages that use HTTP redirections (not meta-refresh). That's the emphasis area; the other aspects have been throughly tested during this cycle.

It seems to detect nonexistent redirect loops a lot -- but not consistently.

I've gone to http://hyperborea.org, which redirects to http://www.hyperborea.org, and sometimes it will work, and sometimes it will complain of a redirect loop.

When testing it from my machine it didn't show any problem after near 30 tries/queries... Are you going out through a proxy?

Similarly, the search form on my blog, which will issue a redirect to the actual article if there is only one result, sometimes works, and sometimes doesn't. (If you're inclined to try testing it, it's at http://www.hyperborea.org/journal/ -- some one-result search terms include meme, delvian, pirates, sharpreader, dairy, pastede -- and that last one isn't a typo.)

Quite weird, I get a complete different number of results: (and it always worked but never redirected) Query | Results ---------------------- meme : 1 delvian : 0 pirates : 3 sharpreader: 1 dairy : 0 pastede : 0

What's strange is that if I close Dillo and reopen it, the ones I've already tried work

Queries never redirected for me. ?? -- Cheers Jorge.-

On Mon, Oct 25, 2004 at 12:27:35AM -0700, Kelson Vibber wrote:

[...] Similarly, the search form on my blog, which will issue a redirect to the actual article if there is only one result, sometimes works, and sometimes doesn't. (If you're inclined to try testing it, it's at http://www.hyperborea.org/journal/ -- some one-result search terms include meme, delvian, pirates, sharpreader, dairy, pastede -- and that last one isn't a typo.)

What's strange is that if I close Dillo and reopen it, the ones I've already tried work

I found a bug that could increment the redirection counter when the HTTP answer is a redirection coming in several tiny packets. The problem is that I can't reproduce the bug anymore! :P Even more, the search is giving me no redirection but a plain 200 OK answer. Look: <q> Nav_open_url: Url=>http://www.hyperborea.org/journal/index.php?s=dairy<; Nav_open_url: redirect_level = 0 Connecting to 204.212.42.2 Header [io_len=116] HTTP/1.1 200 OK Date: Mon, 25 Oct 2004 13:35:00 GMT Server: Apache Connection: close Content-Type: text/html </q> I'll try on a dialup (bigger chance of getting small packets). A way to reproduce it would certainly help, but as it _seems_ to depend on the underlying granularity of packets, this may be hard to achieve... -- Cheers Jorge.-

Jorge Arellano Cid wrote:

I found a bug that could increment the redirection counter when the HTTP answer is a redirection coming in several tiny packets.

Daniel Lord wrote:

What about setting MTU of your ethX to a small number?

Hmm, that might be it. I'm not going through a proxy, but I am going through a broadband router connecting via PPPoE. I just tried it from work, and browsing from my desktop (through the firewall) shows the same problem (on the search form, anyway), but connecting from an outside system (directly over ethernet) seems okay. Jorge Arellano Cid wrote:

Even more, the search is giving me no redirection but a plain 200 OK answer. Look:

Agh. I've got a caching plugin on the journal that saves the HTML output to cut down on database & processing time. It looks like it's caching the search results and just sending them as 200 instead of processing the pre-output part of the script. This explains the apparent inconsistency in which only the first hit triggered the spurious loop error: later hits picked up the cached copy with a 200 instead of a 302. Sorry about that. I've disabled it for now -- the only reason I really had it on was to deal with delays talking to Waypath, but they seem to be down half the time anyway. (In the long term I can set up a separate page to handle searches, and just tell it not to cache that page, but for now, this is simpler.) That should help with the debugging, since I won't have time to put together a test case today. -- Kelson Vibber www.hyperborea.org

On Mon, Oct 25, 2004 at 02:38:33PM -0300, Jorge Arellano Cid wrote:

On Mon, Oct 25, 2004 at 09:37:36AM -0700, Kelson Vibber wrote:

...

[...] Sorry about that.

I've disabled it for now -- the only reason I really had it on was to deal with delays talking to Waypath, but they seem to be down half the time anyway. (In the long term I can set up a separate page to handle searches, and just tell it not to cache that page, but for now, this is simpler.) That should help with the debugging, since I won't have time to put together a test case today.

Don't worry, I'll send (or upload) a patch for you to test. AFAIU, when the hops counter in Dillo detects a redirection Loop (whether real or false), and the next URL requested also gets a redirection code as answer, the latter is mistakenly treated as a redirection loop too.

I'm polishing the patch...

Done. Attached goes the patch, and to the whole list just in case someone else wants to test it ;) --Apply over a clean rc3 tarball This fixes: * Stop button not going off after a redirection loop. * Multiple increases of the redirection hop counter (MTU). * A redirection after a redirection-loop inheriting the failure state. The patch has its debug messages enabled, just in case. As soon as you say it's OK, I'll remove the debugging messages, pack the 0.8.3 tarball and upload to the site for broader testing until the elusive Wednesday release. :-) -- Cheers Jorge.-

On Mon, Oct 25, 2004 at 02:01:08PM -0700, Kelson Vibber wrote:

Jorge Arellano Cid wrote:

...

Attached goes the patch, and to the whole list just in case someone else wants to test it ;) --Apply over a clean rc3 tarball

This fixes:

* Stop button not going off after a redirection loop. * Multiple increases of the redirection hop counter (MTU). * A redirection after a redirection-loop inheriting the failure state.

The patch has its debug messages enabled, just in case.

As soon as you say it's OK, I'll remove the debugging messages, pack the 0.8.3 tarball and upload to the site for broader testing until the elusive Wednesday release. :-)

Looks good. Tested against hyperborea.org (where I saw the spurious errors before) and against mosquito.wordpress.org (where it was originally trapped in the redirect loop). On the latter, with cookies disabled it correctly detects the loop and stops, and with cookies enabled it correctly reloads the first page, picking up the new 200 status instead of reusing the old 302 status, and shows the resulting page.

OK, I also tested mosquito... :-) Well, I packed 0.8.3 and uploaded it for testing. It should have been called rc4, but hopefully this is the last one. More on this on my next email.

Thanks for the last-minute fix!

Thanks to you Kelson for the debugging, reporting and testing. Now 0.8.3 is a lot more polished because of this. -- Cheers Jorge.-

...

...

I found a bug that could increment the redirection counter when the HTTP answer is a redirection coming in several tiny packets.

Daniel Lord wrote:

...

What about setting MTU of your ethX to a small number?

My ISP's proxy/router/gateway/whatever doesn't like to negotiate MTU!, but that's another story...

Can you use your computers built in firewall (iptables/whatever) or use another computer doing the same to get the same effect? Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.