[Dillo-dev]dillo-0.8.3-rc3
Hi there, The tarball for dillo-0.8.3-rc3 is ready for download and testing. This is rc2 plus the fixes for cookies and the redirection loop (i.e. not current CVS). 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. Get it from: http://www.dillo.org/download/dillo-0.8.3-rc3.tar.bz2 The plan is to announce 0.8.3 on Wed 27. Please send your feedback! -- Cheers Jorge.-
In article <20041022151638.GC1771@dillo.org>, Jorge Arellano Cid <jcid@dillo.org> writes
Hi there,
The tarball for dillo-0.8.3-rc3 is ready for download and testing. This is rc2 plus the fixes for cookies and the redirection loop (i.e. not current CVS).
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.
Get it from: http://www.dillo.org/download/dillo-0.8.3-rc3.tar.bz2
The plan is to announce 0.8.3 on Wed 27.
Please send your feedback!
builds OK on the ps2. Not having much luck with my other request. I intend to build rpms both with and without ssl for the ps2... (unless someone else would like to) Can someone who regularly builds rpms please send me their spec file (I think that's what I'll need). (I cheerfully admit I've _never_ built one before and usually convert any I have to install straight into .tgz format :-)) I'd like to make the 27 deadline also. Thanks in Anticipation Bob -- robert w hall
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. 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 -- Kelson Vibber www.hyperborea.org
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.-
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
Sorry, I was searching from http://www.hyperborea.org/ and not from http://www.hyperborea.org/journal/. Now I can reproduce it. [I'm analyzing this now ...] -- 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.-
Hi Jorge, On Mon, Oct 25, 2004 at 10:39:49AM -0300, Jorge Arellano Cid wrote:
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...
What about setting MTU of your ethX to a small number? Greetings Daniel -- One wordly wisdom: "Most people use doors, not windows."
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 09:37:36AM -0700, Kelson Vibber wrote:
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?
My ISP's proxy/router/gateway/whatever doesn't like to negotiate MTU!, but that's another story... Theoretical debugging is helping me now. When I finish the patch, as long as Kelson can reproduce and test it, it'll be fine.
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.
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... How much time will you be online. Or at what time (GMT) do you leave? (I want to upload 0.8.3 today for testing and to announce it on Wednesday morning). -- Cheers Jorge.-
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.-
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. Thanks for the last-minute fix! -- Kelson Vibber www.hyperborea.org
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.-
Jorge Arellano Cid wrote:
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...
How much time will you be online. Or at what time (GMT) do you leave? (I want to upload 0.8.3 today for testing and to announce it on Wednesday morning).
Let's see, if I've got the time conversions right, I usually leave work around 10:30 GMT (5:30pm PDT). I have DSL at home, so I can be online pretty much anytime this evening. I'll just make sure I check my email periodically. I'll probably go to sleep around 16:00 GMT (11pm PDT). Just to warn you, I won't have much time during work today, because we've had two servers die this morning. It looks like I'll be busy with that most of the day. If you do send a patch, I'll try to take a few minutes out to build it. -- Kelson Vibber www.hyperborea.org
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.
On Tue, Oct 26, 2004 at 10:26:33AM +0300, Daniel Fairhead 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?
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?
I don't know and have never done it before. Can the local firewall chop the larger incoming TCP packets into smaller ones? (just curious). What I finally did is to deliver small packets from my brain and follow them through the code! ;-). There're many options, one of them is to have a traffic control program that allows customizing (IIRC Sebastian wrote about one long ago...). Another simple to implement idea is to do it from a local CGI: sending a small packet, sleeping for short time, an so on. Txs. -- Cheers Jorge.-
participants (5)
-
Daniel Fairhead -
Daniel Lord -
Jorge Arellano Cid -
Kelson Vibber -
robert w hall