October 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]dillo-0.8.3-rc3

by Daniel Fairhead

> > > 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.

Oct. 26, 2004

[Dillo-dev]dillo-0.8.3

by Jorge Arellano Cid

Hi there, Finally dillo-0.8.3 is ready for download. It should have been named dillo-0.8.3-rc4, but as this release is too much delayed, I took a chance and called it dillo-0.8.3 with the hope of making the official announcement this Wednesday. Please download it and give it a hard try. Notwistanding my hopes, if any BUG is detected in this short period, an rc5 must follow... Please get it at: http://www.dillo.org/download/dillo-0.8.3.tar.bz2 and send your feedback. 36 hours of testing time remain! :-) -- Cheers Jorge.-

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Jorge Arellano Cid

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.-

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Kelson Vibber

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

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Kelson Vibber

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

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Jorge Arellano Cid

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.-

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Jorge Arellano Cid

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.-

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Kelson Vibber

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

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Daniel Lord

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."

Oct. 25, 2004

Re: [Dillo-dev]dillo-0.8.3-rc3

by Jorge Arellano Cid

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.-

Oct. 25, 2004