- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Cache expire header...

by Madis Janson

On Sun, 14 Dec 2003, Tom Lisjac wrote: > I've written a small, Dillo friendly wiki/cms system in php that I'm > hoping to release in a few weeks. During testing (today's cvs), I found > that Dillo's cache wasn't expiring the dynamic pages. Here's the header > I was initially using to disable client caching: > > header("Expires: Sun, 22 Mar 1998 20:00:00 GMT"); > header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); > header("Pragma: no-cache"); > header("Cache-Control: post-check=0, pre-check=0"); > > With this header, Dillo's stdout messages reported "bad clocks"... so I > tried sending the same date for Expires and Last-Modified. Dillo's > stdout came back with: "Forcing min expire 60 on >the url< instead 0". > What does that mean? > you're using my patch? (it remainds, that i should try to clean up the cache patch for Jorge... oh well it's not easy work, i'm afraid...) Bad clocks means that the expiration time seems to be in history (compared to Last-Modified, when this header is present) for dillo at the time when the header was received, and is so more than 1000 seconds. These expirations are ignored, because many sites send these for all their content and it would otherwise cause dillo to always reload everything on these sites. For you're example - 1998 is very long history. Forcing min expire 60 - this is configurable using min_page_expire option in dillorc. When this config option is non-zero, dillo will set expiration times below this value (in seconds) to the config option value. It was introduced to give better speed with stupid news sites. > I really need the content of certain pages to expire immediately when > viewed. Any suggestions for the correct header parameters would be > greatly appreciated. 1. following dillorc options make it most agressivily reload everything: query_expire_time="0" min_page_expire="0" min_image_expire="0" 2. Use Cache-Control header: Cache-Control: no-cache

Dec. 21, 2003

Is something wrong with the cvs repository?

by Matthias Pfeifer

I think the cvs version is currently not working. i do cd src cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo cd dillo automake -a autoconf (without outputs) and then ./configure gives ./configure: line 650: syntax error near unexpected toke `AM_INIT_AUTOMAKE(dillo,' ./configure: line 650: `AM_INIT_AUTOMAKE(dillo,0.8.0-pre)' - Matthias Pfeifer, Aachen/Germany

Dec. 19, 2003

ChessBrain: World Record!

by The ChessBrain Network

The ChessBrain Network T o be removed from our mailing list, send an email to support(a)chessbrain.net

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Andreas Tolfsen

Daniel wrote: >Hi Jan, > >On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > > >>why does Dillo not send the referer header? Without it, I >>cannot use the http://validator.w3.org/check/referer link, >>as appearing on the bottom of my pages. >> >> >referer == evil > >>his is the only problem which keeps mozilla on my machine. >> >> >It's not a problem it's a feature. And the reason I use Dillo not >Mozilla *g* > >Daniel > > Well, personally, I think there should be an option for turning it on and off maybe? Wouldn't that please everybody?

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Daniel

Hi Jan, On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > why does Dillo not send the referer header? Without it, I > cannot use the http://validator.w3.org/check/referer link, > as appearing on the bottom of my pages. referer == evil > This is the only problem which keeps mozilla on my machine. It's not a problem it's a feature. And the reason I use Dillo not Mozilla *g* Daniel -- Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails noch bei Kerzenlicht geschrieben haben... [Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000]

Dec. 19, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Sebastian Geerken

On Sun, Nov 23, Frank de Lange wrote: > Paul Pelzl wrote: > >I've got a couple of early bugs to report: > > > >1) when using kbnav to move from a link to an entry box in a form, the > > most recently selected link is not properly deselected. Example: > > google.com. > > > > > If this is what I think it is, it actually seems to be a widget bug. > I've discussed this with Sebastian before. Relevant part of discussion > plus link to bug description: This is bug #202, and has been fixed now in CVS (positive result also with Frank's keyboard navigation patch). This fix is a bit difficult to test, so I've committed it after relatively short testing time on my side, and ask the list for any experience (bugs, CPU load etc). Sebastian

Dec. 19, 2003

sending referer

by Jan Stary

Hello, why does Dillo not send the referer header? Without it, I cannot use the http://validator.w3.org/check/referer link, as appearing on the bottom of my pages. This is the only problem which keeps mozilla on my machine. Thank you Jan

Dec. 19, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorge Arellano Cid

On Wed, 17 Dec 2003, Jorgen Viksell wrote: > Hi, > > I've actually got a patch for this. It's just that it's part of a larger > patch to clean up configure.in. > I can split these changes out and send it to you in a couple of days. > > Jörgen Excellent! Greetings Jorge.-

Dec. 18, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorgen Viksell

Hi, I've actually got a patch for this. It's just that it's part of a larger patch to clean up configure.in. I can split these changes out and send it to you in a couple of days. Jörgen ons 2003-12-17 klockan 20.58 skrev Jorge Arellano Cid: > Hi guys, > > I just noticed that out automake process ends linking all the > libraries required by dillo to dpid and every dpi! > > For instance: > > $ldd dpid > libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) > libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) > libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) > libdl.so.2 => /lib/libdl.so.2 (0x40239000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) > libm.so.6 => /lib/libm.so.6 (0x40311000) > libc.so.6 => /lib/libc.so.6 (0x40334000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Wow! > > And the kernel reports: > > VmSize: 4684 kB > VmLck: 0 kB > VmRSS: 1160 kB > VmData: 304 kB > VmStk: 16 kB > VmExe: 24 kB > VmLib: 4208 kB > > This means that resident dpis (servers) can end wasting virtual > memory after dillo exits by retaining unused libs in VmLib. > > If someone here can make a patch for this problem, it'd be a > great time saver. Please? :-) > > > Cheers > Jorge.-

Dec. 17, 2003

Automake and dynamic linking

by Jorge Arellano Cid

Hi guys, I just noticed that out automake process ends linking all the libraries required by dillo to dpid and every dpi! For instance: $ldd dpid libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) libdl.so.2 => /lib/libdl.so.2 (0x40239000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) libm.so.6 => /lib/libm.so.6 (0x40311000) libc.so.6 => /lib/libc.so.6 (0x40334000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Wow! And the kernel reports: VmSize: 4684 kB VmLck: 0 kB VmRSS: 1160 kB VmData: 304 kB VmStk: 16 kB VmExe: 24 kB VmLib: 4208 kB This means that resident dpis (servers) can end wasting virtual memory after dillo exits by retaining unused libs in VmLib. If someone here can make a patch for this problem, it'd be a great time saver. Please? :-) Cheers Jorge.-

Dec. 17, 2003