- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] 0.8.6rcx testing on ps2

by Jorge Arellano Cid

Hi, On Thu, Apr 13, 2006 at 06:53:50PM +0100, robert w hall wrote: > I'm still investigating this message below from cronocloud. The first > bit is more concerning (but was it rc3 or 4? - I don't yet know) than > the 2nd. > > The second point is probably because he's still got the v6 d/l in place > > Read and respond to this message at: > https://playstation2-linux.com/forum/message.php?msg_id=49497 > By: cronocloud > > I reverted to 0.8.5, the new downloader only worked for me once, as far > as I > could tell. And even if I recompiled with --disable-dlgui it still > wouldn't > download properly. It's very important not to mix versions, and to be careful. This is: dpidc stop make make install-strip (be sure not to have old dpis under ~/.dillo/ too!). test BTW, Friday or Saturday rc5 could be out. -- Cheers Jorge.-

April 13, 2006

0.8.6rcx testing on ps2

by robert w hall

I'm still investigating this message below from cronocloud. The first bit is more concerning (but was it rc3 or 4? - I don't yet know) than the 2nd. The second point is probably because he's still got the v6 d/l in place Read and respond to this message at: https://playstation2-linux.com/forum/message.php?msg_id=49497 By: cronocloud I reverted to 0.8.5, the new downloader only worked for me once, as far as I could tell. And even if I recompiled with --disable-dlgui it still wouldn't download properly. I -- robert w hall

April 13, 2006

Re: [Dillo-dev] rc4 testing

by Diego Sáenz

All well for me. Diego. El Wed, 12 Apr 2006 10:59:52 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi there, > > On Mon, Apr 10, 2006 at 08:23:33PM +0200, Diego Sáenz wrote: > > Is it too late for a small hack? > > dl_gui is not localized, but wget yes. When you have a locale diferent from "C" or one english one dl_gui do not get the download size (it search for "Lenght:" in wget log) and progress bar do not show real progress. > > > > How i unknown how portables are locale functions y use puntenv to change locale environ and set wget(and its log) to "C" > > A better solution can be to localize dl_gui or generalize wget parser > > The patchset for downloads GUI is in CVS now. This is: > > - LC_ALL=C > - cookies > - Last download goes on top > (please send feedback on this) > > NOTE: please use FLTK2 r4898 or less. The latest versions are too > unstable or simply crash. > > From scratch from svn: > > svn co -r 4898 http://svn.easysw.com/public/fltk/fltk/trunk/ fltk > > to an existing svn tree: > > svn update -r 4898 > > > If I don't get more bug reports from rc4 in a couple of days, I'll > expect Diego's feedback and pack rc5 with CVS. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 13, 2006

Re: [Dillo-dev] rc4 testing

by Jorge Arellano Cid

Hi there, On Mon, Apr 10, 2006 at 08:23:33PM +0200, Diego Sáenz wrote: > Is it too late for a small hack? > dl_gui is not localized, but wget yes. When you have a locale diferent from "C" or one english one dl_gui do not get the download size (it search for "Lenght:" in wget log) and progress bar do not show real progress. > > How i unknown how portables are locale functions y use puntenv to change locale environ and set wget(and its log) to "C" > A better solution can be to localize dl_gui or generalize wget parser The patchset for downloads GUI is in CVS now. This is: - LC_ALL=C - cookies - Last download goes on top (please send feedback on this) NOTE: please use FLTK2 r4898 or less. The latest versions are too unstable or simply crash. From scratch from svn: svn co -r 4898 http://svn.easysw.com/public/fltk/fltk/trunk/ fltk to an existing svn tree: svn update -r 4898 If I don't get more bug reports from rc4 in a couple of days, I'll expect Diego's feedback and pack rc5 with CVS. -- Cheers Jorge.-

April 12, 2006

Re: [Dillo-dev] rc4 testing

by Jorge Arellano Cid

Hi Diego, On Mon, Apr 10, 2006 at 08:23:33PM +0200, Diego Sáenz wrote: > Is it too late for a small hack? Still time to squash bugs. > dl_gui is not localized, but wget yes. When you have a locale diferent from "C" or one english one dl_gui do not get the download size (it search for "Lenght:" in wget log) and progress bar do not show real progress. > > How i unknown how portables are locale functions y use puntenv to change locale environ and set wget(and its log) to "C" > A better solution can be to localize dl_gui or generalize wget parser > > > diff -pru dillo-0.8.6-rc4-C/dpi/downloads.cc dillo-0.8.6-rc4/dpi/downloads.cc > --- dillo-0.8.6-rc4-C/dpi/downloads.cc 2006-04-10 19:47:00.000000000 +0200 > +++ dillo-0.8.6-rc4/dpi/downloads.cc 2006-04-10 19:48:26.000000000 +0200 > @@ -458,6 +458,8 @@ void DLItem::child_init() > close(1); // stdout > close(LogPipe[0]); > dup2(LogPipe[1], 2); // stderr > + // put locale to C (small hack) dl_gui search for "Lenght:" in wget log > + putenv("LC_ALL=C"); > // start wget > execvp(dl_argv[0], dl_argv); > } I prefer setenv(), because with putenv() you have to define _XOPEN_SOURCE or _SVID_SOURCE. > > If i get time i will try to support dillo cookies file. It is only add "--load-cookies $HOME/.dillo/cookies.txt" to wget comandline. May be this work (not tested, can anyone test and report?) > > > diff -pru dillo-0.8.6-rc4-C/dpi/downloads.cc dillo-0.8.6-rc4/dpi/downloads.cc > --- dillo-0.8.6-rc4-C/dpi/downloads.cc 2006-04-10 20:20:30.000000000 +0200 > +++ dillo-0.8.6-rc4/dpi/downloads.cc 2006-04-10 20:20:11.000000000 +0200 > @@ -325,7 +325,7 @@ DLItem::DLItem(const char *full_filename > /* avoid malicious SMTP relaying with FTP urls */ > if (g_strncasecmp(esc_url, "ftp:/", 5) == 0) > Filter_smtp_hack(esc_url); > - dl_argv = new char*[6]; > + dl_argv = new char*[7]; > int i = 0; > dl_argv[i++] = "wget"; > if (action == DL_CONTINUE) { > @@ -336,6 +336,7 @@ DLItem::DLItem(const char *full_filename > dl_argv[i++] = "-O"; > dl_argv[i++] = fullname; > dl_argv[i++] = esc_url; //g_strdup_printf("'%s'", esc_url); > + dl_argv[i++] = "--load-cookies $HOME/.dillo/cookies.txt"; > dl_argv[i++] = NULL; > //g_free(esc_url); > AFAIU that code will not work (setting two arguments in one place)... > > But i do not understand this lines in DLItem::~DLItem() > > if (dl_argv[4] == NULL) > g_free(dl_argv[3]); > else > g_free(dl_argv[4]); > delete(dl_argv); > > ¿do not change arguments order if "-c" is used or not? Yes, but it's buggy! ;) All of it is fixed in my tree, but FLTK2 last version breaks lots of things so I'm going back for testing. :-P BTW, I have the idea of adding new downloads on top instead of bottom. That way you always see the fresh download you started, no matter what the size of the window. I'll test this with an older FLTK2 version and commit for your testing pleasure. ;) -- Cheers Jorge.-

April 11, 2006

Upcoming filename changes in FLTK2

by Jeremy Henty

A tip-off for Dillo developers: FLTK2 will shortly rename its installed libraries and configuration scripts from *fltk* to *fltk2* . This means that Dillo's configure.in will then have to refer to fltk2-config everywhere instead of fltk-config . Cheers, Jeremy Henty

April 10, 2006

Re: [Dillo-dev] rc4 testing

by Diego Sáenz

Is it too late for a small hack? dl_gui is not localized, but wget yes. When you have a locale diferent from "C" or one english one dl_gui do not get the download size (it search for "Lenght:" in wget log) and progress bar do not show real progress. How i unknown how portables are locale functions y use puntenv to change locale environ and set wget(and its log) to "C" A better solution can be to localize dl_gui or generalize wget parser diff -pru dillo-0.8.6-rc4-C/dpi/downloads.cc dillo-0.8.6-rc4/dpi/downloads.cc --- dillo-0.8.6-rc4-C/dpi/downloads.cc 2006-04-10 19:47:00.000000000 +0200 +++ dillo-0.8.6-rc4/dpi/downloads.cc 2006-04-10 19:48:26.000000000 +0200 @@ -458,6 +458,8 @@ void DLItem::child_init() close(1); // stdout close(LogPipe[0]); dup2(LogPipe[1], 2); // stderr + // put locale to C (small hack) dl_gui search for "Lenght:" in wget log + putenv("LC_ALL=C"); // start wget execvp(dl_argv[0], dl_argv); } If i get time i will try to support dillo cookies file. It is only add "--load-cookies $HOME/.dillo/cookies.txt" to wget comandline. May be this work (not tested, can anyone test and report?) diff -pru dillo-0.8.6-rc4-C/dpi/downloads.cc dillo-0.8.6-rc4/dpi/downloads.cc --- dillo-0.8.6-rc4-C/dpi/downloads.cc 2006-04-10 20:20:30.000000000 +0200 +++ dillo-0.8.6-rc4/dpi/downloads.cc 2006-04-10 20:20:11.000000000 +0200 @@ -325,7 +325,7 @@ DLItem::DLItem(const char *full_filename /* avoid malicious SMTP relaying with FTP urls */ if (g_strncasecmp(esc_url, "ftp:/", 5) == 0) Filter_smtp_hack(esc_url); - dl_argv = new char*[6]; + dl_argv = new char*[7]; int i = 0; dl_argv[i++] = "wget"; if (action == DL_CONTINUE) { @@ -336,6 +336,7 @@ DLItem::DLItem(const char *full_filename dl_argv[i++] = "-O"; dl_argv[i++] = fullname; dl_argv[i++] = esc_url; //g_strdup_printf("'%s'", esc_url); + dl_argv[i++] = "--load-cookies $HOME/.dillo/cookies.txt"; dl_argv[i++] = NULL; //g_free(esc_url); But i do not understand this lines in DLItem::~DLItem() if (dl_argv[4] == NULL) g_free(dl_argv[3]); else g_free(dl_argv[4]); delete(dl_argv); ¿do not change arguments order if "-c" is used or not? Diego. El Sun, 9 Apr 2006 19:44:43 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi, > > Kelson told me the patch in CVS works for the web bug segfault. > > It looks like we're close to a release. > > I'll wait a couple of days more for feedback. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 10, 2006

rc4 testing

by Jorge Arellano Cid

Hi, Kelson told me the patch in CVS works for the web bug segfault. It looks like we're close to a release. I'll wait a couple of days more for feedback. -- Cheers Jorge.-

April 9, 2006

Dillo 0.8.6 RC4 on a ps2 (with fltk2 dpi)

by robert w hall

In article <4436969B.8080202(a)pobox.com>, Kelson Vibber <kelson(a)pobox.com> writes >I'm seeing far fewer problems with this one so far! Better news on the ps2/fltk2 front (but not much better) I've got a version of fltk2 (4922) to compile, using gcc3.03 and an updated autoconf (2.57). Also small fixes to xutf8 and fltk/glut.h. But it looks like that condemns me (and those others who usually 'roll their own') to using the later gcc3.03 gcc and g++ packages throughout, installing the new autoconf and declaring new paths to CC and CXX in configure. (but at least 'mine eyes have seen' fltk2 in action) -- robert w hall

April 9, 2006

Re: [Dillo-dev] dillo-0.8.6-rc4.tar.bz2

by Thomas-Martin Seck

* Thomas-Martin Seck (tmseck-lists(a)netcologne.de) > * Jorge Arellano Cid (jcid(a)dillo.org) > > > The new rc4 tarball is ready: > > > > http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 > > As usual, compiles on FreeBSD 4, 5, and 6 with a tarball fetched a few > hours ago. Normal usage on FreeBSD 4 and 6 shows no issues whatsoever, > luckily not even the segfault conditions Kelson Vibber had already > reported. Did you reroll the tarball to include the fixes for this? A minor issue: when I try to build dillo against a non-threaded fltk2, I get this: c++ -I/usr/local/include/glib12 -O -pipe -L/usr/local/lib -L/usr/X11R6/lib -L/usr/local/lib -o downloads.dpi downloads.o dpiutil.o -L/usr/local/lib -lglib-12 -L/usr/X11R6/lib -lfltk -L/usr/local/lib -lX11 -lXi -lXinerama -lXft -lm -lXext ../dpip/libDpip.a downloads.o: In function `main': downloads.o(.text+0x2fca): undefined reference to `fltk::lock(void)' gmake[2]: *** [downloads.dpi] Error 1 This is probably to be expected? This is not a big issue, I'll just add a note that people who want to use dillo+fltk2 make sure they install fltk2 with threads support. Threads support is turned on by default but can be turned off if the user wants to. (This can be useful on FreeBSD 4 which has no threads support beyond libc_r.)

April 9, 2006

Re: [Dillo-dev] dillo-0.8.6-rc4.tar.bz2

by Jorge Arellano Cid

On Sun, Apr 09, 2006 at 02:34:15PM +0200, Thomas-Martin Seck wrote: > * Jorge Arellano Cid (jcid(a)dillo.org) > > > The new rc4 tarball is ready: > > > > http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 > > As usual, compiles on FreeBSD 4, 5, and 6 with a tarball fetched a few > hours ago. Normal usage on FreeBSD 4 and 6 shows no issues whatsoever, > luckily not even the segfault conditions Kelson Vibber had already > reported. Did you reroll the tarball to include the fixes for this? Thanks for the feedback. I haven't made a rc5 tarball yet; I'm waiting for more feedback. This way I can pack all the detected bugs into rc5, or if there're only a few bugs, pack a "final" one. The fix for the bug reported by Kelson is in the CVS now. -- Cheers Jorge.-

April 9, 2006

Re: [Dillo-dev] dillo-0.8.6-rc4.tar.bz2

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > The new rc4 tarball is ready: > > http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 As usual, compiles on FreeBSD 4, 5, and 6 with a tarball fetched a few hours ago. Normal usage on FreeBSD 4 and 6 shows no issues whatsoever, luckily not even the segfault conditions Kelson Vibber had already reported. Did you reroll the tarball to include the fixes for this?

April 9, 2006

Re: [Dillo-dev] Segfault in Dillo 0.8.6 RC4

by Jorge Arellano Cid

Hi Kelson, On Fri, Apr 07, 2006 at 09:43:07AM -0700, Kelson Vibber wrote: > I'm seeing far fewer problems with this one so far! > > I did find a page that made RC4 segfault, though. > > I tracked the segfault to an image where the src URL was missing a > Content-Type header. (The URL also had a content-length of 0, but that > alone doesn't cause Dillo any problems.) It occurred whether I pointed > Dillo at a page containing the <img> element, or pointed it straight at > the image URL. > > RC3 does not segfault on this URL. (It just displays an empty page or > image.) > > I'm reluctant to post the actual URL because it's a web bug, but here > are the headers as reported by the libwww HEAD command: > > 200 OK > Cache-Control: private > Date: Fri, 07 Apr 2006 16:17:06 GMT > Server: Microsoft-IIS/6.0 > Content-Length: 0 > MicrosoftOfficeWebServer: 5.0_Pub > P3P: CP="PUB OTRo" > Set-Cookie: SIClientID=108; path=/ > X-AspNet-Version: 1.1.4322 > X-Powered-By: ASP.NET > > > Here's the debug output from Dillo: > > HTTP warning: Server didn't send Content-Type in header. > Type check: [Srv: (null) Det: text/plain] > Segmentation fault > > > I've been trying to put together a test case, but Apache won't let me > send a response without a content-type, even through CGI. If I don't > create a Content-Type header, it adds one using the default type and > encoding. Thanks a lot for the report! Bug fixed in CVS, please check it. FWIW, I used boa web server. :-) -- Cheers Jorge.-

April 8, 2006

Segfault in Dillo 0.8.6 RC4

by Kelson Vibber

I'm seeing far fewer problems with this one so far! I did find a page that made RC4 segfault, though. I tracked the segfault to an image where the src URL was missing a Content-Type header. (The URL also had a content-length of 0, but that alone doesn't cause Dillo any problems.) It occurred whether I pointed Dillo at a page containing the <img> element, or pointed it straight at the image URL. RC3 does not segfault on this URL. (It just displays an empty page or image.) I'm reluctant to post the actual URL because it's a web bug, but here are the headers as reported by the libwww HEAD command: 200 OK Cache-Control: private Date: Fri, 07 Apr 2006 16:17:06 GMT Server: Microsoft-IIS/6.0 Content-Length: 0 MicrosoftOfficeWebServer: 5.0_Pub P3P: CP="PUB OTRo" Set-Cookie: SIClientID=108; path=/ X-AspNet-Version: 1.1.4322 X-Powered-By: ASP.NET Here's the debug output from Dillo: HTTP warning: Server didn't send Content-Type in header. Type check: [Srv: (null) Det: text/plain] Segmentation fault I've been trying to put together a test case, but Apache won't let me send a response without a content-type, even through CGI. If I don't create a Content-Type header, it adds one using the default type and encoding. -- Kelson Vibber www.hyperborea.org

April 7, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

In article <20060406120500.GF13477(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Don't stress yourself too much, after all there's the >`./configure --disable-dlgui` option. This works of course, ... > > It will be more important when all of Dillo becomes FLTK2-based. Which is why it's important I feel to try it out now :-) > > -- robert w hall

April 6, 2006

Re: [Dillo-dev] fltk2 on the ps2

by robert w hall

In article <20060406123034.GG13477(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Yes, try in xutf8.cxx:897 > >- const char* inbuf = mb_buffer; >+ char* inbuf = mb_buffer; > > Good call - but now it collapses in a set of link-time errors (unresolved refs) in fluid.... -- robert w hall

April 6, 2006

Re: [Dillo-dev] fltk2 on the ps2

by Jorge Arellano Cid

On Thu, Apr 06, 2006 at 09:00:24AM +0100, robert w hall wrote: > I'm still trying to get a clean compilation of fltk2 on the > playstation2. > > Switching compilers (the default is 2.95.2 IIRC) to the slightly > experimental package of gcc3.0.3 has allowed me to get everything to > compile 'as is' apart from run.cxx, which give the following 'error' > > In file included from x11/run.cxx:55, > from run.cxx:185: > x11/xutf8.cxx: In function `int Xutf8LookupString(_XIC*, XKeyPressedEvent*, > char*, int, KeySym*, int*)': > x11/xutf8.cxx:901: cannot convert `const char**' to `char**' for argument `2' > to `size_t iconv(void*, char**, size_t*, char**, size_t*)' > make[1]: *** [run.o] Error 1 > make: *** [all] Error 2 > > > Any advice?? Yes, try in xutf8.cxx:897 - const char* inbuf = mb_buffer; + char* inbuf = mb_buffer; -- Cheers Jorge.-

April 6, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi Bob, On Tue, Apr 04, 2006 at 07:18:40PM +0100, robert w hall wrote: > I > > > >OK this gets me by this one, thanks Martin. > >But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h > >and filename.h 'parse error before *' lines 100+ > >>______________ > Looks like I'm on my own :-( > - but there's a rather hairy ('experimental') gcc3.03 on the ps2-linux > site I see..... Don't stress yourself too much, after all there's the `./configure --disable-dlgui` option. It will be more important when all of Dillo becomes FLTK2-based. -- Cheers Jorge.-

April 6, 2006

Re: [Dillo-dev] fltk2 on the ps2

by Jeremy Henty

On Thu, Apr 06, 2006 at 09:00:24AM +0100, robert w hall wrote: > I'm still trying to get a clean compilation of fltk2 on the > playstation2. > > Any advice?? Um, ask the FLTK developers? http://www.fltk.org/newsgroups.php http://lists.easysw.com/mailman/listinfo Jeremy Henty

April 6, 2006

fltk2 on the ps2

by robert w hall

I'm still trying to get a clean compilation of fltk2 on the playstation2. Switching compilers (the default is 2.95.2 IIRC) to the slightly experimental package of gcc3.0.3 has allowed me to get everything to compile 'as is' apart from run.cxx, which give the following 'error' In file included from x11/run.cxx:55, from run.cxx:185: x11/xutf8.cxx: In function `int Xutf8LookupString(_XIC*, XKeyPressedEvent*, char*, int, KeySym*, int*)': x11/xutf8.cxx:901: cannot convert `const char**' to `char**' for argument `2' to `size_t iconv(void*, char**, size_t*, char**, size_t*)' make[1]: *** [run.o] Error 1 make: *** [all] Error 2 Any advice?? -- robert w hall

April 6, 2006

Re: [Dillo-dev] dillo-0.8.6-rc4.tar.bz2

by Jeremy Henty

On Wed, Apr 05, 2006 at 06:52:22PM -0400, Jorge Arellano Cid wrote: > http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 Works correctly with all the problem pages I found with -rc3. Haven't used it on MP3s yet. Cheers, Jeremy Henty

April 6, 2006

dillo-0.8.6-rc4.tar.bz2

by Jorge Arellano Cid

Hi there! The new rc4 tarball is ready: http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 This is complex stuff... From the solutions list: 1.- Keep it as is 2.- Do Content-type sniffing and follow the SPEC. i.e. as stated above, to take the right of ignoring the offending contents. 3.- Do Content-type sniffing and take actions (like mozilla). rc4 implements solution number 2. Specifically: /* * A mismatch happens when receiving a binary stream as * "text/plain" or "text/html", or an image that's not an image of its kind. */ It was tested against all the test cases sent so far. Please test it throughly. Note: It would be nice to popup a dialog window with a warning in some cases (user friendliness). Now, as it is now it is much better than 0.8.5, because binaries are never downloaded into main memory and there're some warning messages. Maybe the dialog warning can wait for the next release, or if testing finds it's necessary, the release can be procrastinated some more. Subtle Note: as it is, it follows the SPEC. The only action taken is to ignore offending contents. A dialog with a warning and offering download/cancel options would be in the gray line between the SPEC and taking actions. -- Cheers Jorge.-

April 5, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

I > >OK this gets me by this one, thanks Martin. >But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h >and filename.h 'parse error before *' lines 100+ >>______________ Looks like I'm on my own :-( - but there's a rather hairy ('experimental') gcc3.03 on the ps2-linux site I see..... -- robert w hall

April 4, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

In article <20060402101918.GA1052(a)hardy.tmseck.homedns.org>, Thomas- Martin Seck <tmseck-lists(a)netcologne.de> writes >Could you try this patch? It is stolen from fltk's bug database, >STR#1124. It enables me to compile fltk2 r4825 with gcc 2.95.4 on >FreeBSD. > >--- fltk/ComboBox.h.orig Sun Apr 2 12:05:31 2006 >+++ fltk/ComboBox.h Sun Apr 2 12:07:16 2006 >@@ -103,7 +103,7 @@ > ComboBox *combo_; > }; > ComboInput *input_; >-#ifdef _WIN32 >+#if defined ( _WIN32 ) || defined ( __GNUC__ ) && __GNUC__ < 3 > public: > #endif > static void input_callback_(Widget*,void*); > >__ OK this gets me by this one, thanks Martin. But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h and filename.h 'parse error before *' lines 100+ >_____________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- robert w hall

April 3, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Kelly Price

On 4/2/06, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > 1.- Keep it as is > 2.- Do Content-type sniffing and follow the SPEC. i.e. as > stated above, to take the right of ignoring the offending > contents. > 3.- Do Content-type sniffing and take actions (like mozilla). > > > I like best the second one. Basically this is, If I get a > binary stream as "text/plain" or "text/html", or an image that's > not an image, then issue a warning and ignore it (abort). Note: > this is a basic security procedure. > > This has the advantege of protecting the browser against > attacks and following the SPEC. The user is left to decide (for > instance to retry with "save link as"). > > The third option looks more "user friendly" but it goes against > the SPEC. > Just to delurk and make a note here. The second one would be spec, but third one is both user friendly and server friendly in limited cases. Take for example VCL and Comic Genesis (which I admin). To prevent inlining of images on outside servers and general bandwith wastage, we've programmed the server to check the Referer: header. CG's a bit stricter than VCL is with broken browsers and proxies that don't send (or worse, strip) a Referer: header, but both check to see if the request for an image is for a page it just served. If the check fails, CG sends out a 403 and shoots out a HTML page saying so. VCL redirects to a HTML page which shows the image itself. In ether case, Mozilla/IE/Konqueror/Safari just say that the image is broken in the non-VCL/CG webpage it pulled. If it was directly requested, VCL pulls the HTML/IMG up. CG 403's. If I remember correctly, Mozilla actually asks for an image MIME type first, and then a */* MIME type as a catchall. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi, Thanks for the excellent information! Don't worry guys, this patch obviously needs major rethinking. Please read these articles (suggested in this thread): http://www.mozilla.org/docs/web-developer/mimetypes.html http://diveintomark.org/archives/2004/08/13/safari-content-sniffing http://ppewww.ph.gla.ac.uk/%7Eflavell/www/content-type.html It's somewhat funny. The third one has thoughtful comments and suggestions; it attacks IE for its against-specs content-type sniffing. Note that the first article shows that mozilla is doing this too (I guess not for the same reasons though :-). The second one shows a shameful case of browser-sniffing bugs. This is a complex problem, but has some solutions. BTW, I agree a lot with what Kelson wrote (attached below). On Thu, Mar 30, 2006 at 02:16:36PM -0800, Kelson Vibber wrote: > Yeah, I'm seeing problems as well. > > Putting the character set into the Content-Type header in the form > 'text/html; charset=utf-8' is actually recommended by the W3C: > http://www.w3.org/International/O-HTTP-charset > > Some of the problems with the current implementation might be resolved > by normalizing the content-type. > > In general, I'm not a big fan of content sniffing unless it's done in > very limited circumstances. Often the server has a reason to use that > content-type. > > The way Mozilla handled this was to only do content sniffing if the > server used text/plain. It's more likely that you'll find a server > that's sending the default type* than one that's deliberately serving > something incorrect.** > http://www.mozilla.org/docs/web-developer/mimetypes.html > > Even then, you have to be careful, as illustrated here: > http://diveintomark.org/archives/2004/08/13/safari-content-sniffing > It's a text document, properly served as text/plain, that mentions XHTML > in the first line. The then-current version of Safari decided to render > it as XHTML. > > * Apache uses a default of text/plain for all files it can't identify. > I think this is a bad idea, but it's probably still used for historical > reasons. IIS uses application/octet-stream, which doesn't tell you > anything, but at least it usually triggers a download instead of trying > to display binary data as text. This is one of those rare cases where I > think IIS got it right and Apache got it wrong. > > ** This is also why so many RPM packages are served as RealPlayer files. > RealPlayer was the first popular use for the .rpm extension, so lots of > servers got configured that way. > > -- > Kelson Vibber > www.hyperborea.org and also want to quote this part from te third article: <q> The HTTP protocol specifications (1.0 and 1.1) effectively forbid a browser that has received a valid Content-type header from the server, from making its own unilateral determination of the content-type - see RFC2616 section 7.2.1 (my emphasis): If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. The consequences of this when a server is misconfigured aren't always immediately evident; for example, consider an HTML page (sent out correctly as text/html) which calls out a stylesheet and a number of in-lined images: if the server sends these out with a wrong Content-type, then the browser might be displaying the HTML page's main content, but the browser has every right to ignore the offending stylesheet, or to omit the offending image(s) from the display: indeed a strict interpretation of the rules would say that it must behave that way. Faking the wrong Content-type from the server is potentially a way of compromising security, so there's a genuine reason for this rule being the way that it is. </q> Solutions I see so far: 1.- Keep it as is 2.- Do Content-type sniffing and follow the SPEC. i.e. as stated above, to take the right of ignoring the offending contents. 3.- Do Content-type sniffing and take actions (like mozilla). I like best the second one. Basically this is, If I get a binary stream as "text/plain" or "text/html", or an image that's not an image, then issue a warning and ignore it (abort). Note: this is a basic security procedure. This has the advantege of protecting the browser against attacks and following the SPEC. The user is left to decide (for instance to retry with "save link as"). The third option looks more "user friendly" but it goes against the SPEC. Note: One huge problem of option 1, is that if you start a download this way, it ends in _main memory_. If you get an ISO or movie, eventually the browser will trigger swapping or abort (out-of-memory) and lose the file and time spent on the download. A No-no. -- Cheers Jorge.-

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi, On Sat, Apr 01, 2006 at 02:13:05PM +0100, robert w hall wrote: > In article <FCZNR2Ai+lLEFwiV(a)n-cantrell.demon.co.uk>, robert w hall > <bobh(a)n-cantrell.demon.co.uk> writes > >But, the latest fltk does not compile on the ps2 (...'input_callback...' > >is private) - looks like the age of the ps2 base-distribution may be > >catching us out? > > > > > but fltk-1.1.7 _does_ compile OK - is it possible to fix the download > dpi to run with the earlier version this time? Unfortunately not. -- Cheers Jorge.-

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi, On Sun, Apr 02, 2006 at 12:19:18PM +0200, Thomas-Martin Seck wrote: > [...] > fltk2 needs gcc 3 to compile "as is" - does linux/ps2 only come with gcc > 2.95? > > This bites me on FreeBSD 4, too, where the system compiler is gcc > 2.95.4. > > (Not counting the fact that snapshots past 4825 do not compile with gcc > 3.4.x either, sigh.) Yes, the latest online versions have had some compilation problems. Revision 4886 works great here though. > > Could you try this patch? It is stolen from fltk's bug database, > STR#1124. It enables me to compile fltk2 r4825 with gcc 2.95.4 on > FreeBSD. > > --- fltk/ComboBox.h.orig Sun Apr 2 12:05:31 2006 > +++ fltk/ComboBox.h Sun Apr 2 12:07:16 2006 > @@ -103,7 +103,7 @@ > ComboBox *combo_; > }; > ComboInput *input_; > -#ifdef _WIN32 > +#if defined ( _WIN32 ) || defined ( __GNUC__ ) && __GNUC__ < 3 > public: > #endif > static void input_callback_(Widget*,void*); > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Cheers Jorge.-

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > Hi there! > > The new dillo-0.8.6-rc3 tarball is ready for download. Get it > from: > > http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 Compiles and works on FreeBSD 4, 5, and 6 with and without downloads.dpi. > Finally I decided to include a big patch for the MIME type > detection and its handling. This is an important change in the > way Dillo treats its incoming files (HTTP streams). > > The point: as this release comes with a new downloads GUI, and > downloads are mainly the focus, I disliked the situation where a > Web server "lied" with regard to the Content/Type of a file. I am not too happy with this. As already pointed out on this list, mp3's will be treated as test because they start with "ID3". There may be other interesting cases: When I first read your post, I immediately thought of Windows' Explorer and the WMF vulnerability - no matter how you named a WMF file, it would always be rendered as if it were named .wmf, completely breaking Windows POLA where the extension of a file is authoritative. You might open an interesting backdoor with content sniffing applications. Is is possible to make this a compile time/runtime option somehow, defaulting to disabled?

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Thomas-Martin Seck

* robert w hall (bobh(a)n-cantrell.demon.co.uk) > In article <$N7zyiApBaLEFw0m(a)n-cantrell.demon.co.uk>, robert w hall > <bobh(a)n-cantrell.demon.co.uk> writes > >I _hope_ to test on the ps2 over the weekend, when I can get the creaky > >box back up proerly > >Bob > > > > > >In article <20060330155817.GC29028(a)dillo.org>, Jorge Arellano Cid > ><jcid(a)dillo.org> writes > >>Hi there! > >> > >> The new dillo-0.8.6-rc3 tarball is ready for download. Get it > >>from: > >> > >> http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 > OK, I can compile this with --disable-dlgui (for this relief much > thanks...) > > But, the latest fltk does not compile on the ps2 (...'input_callback...' > is private) - looks like the age of the ps2 base-distribution may be > catching us out? fltk2 needs gcc 3 to compile "as is" - does linux/ps2 only come with gcc 2.95? This bites me on FreeBSD 4, too, where the system compiler is gcc 2.95.4. (Not counting the fact that snapshots past 4825 do not compile with gcc 3.4.x either, sigh.) Could you try this patch? It is stolen from fltk's bug database, STR#1124. It enables me to compile fltk2 r4825 with gcc 2.95.4 on FreeBSD. --- fltk/ComboBox.h.orig Sun Apr 2 12:05:31 2006 +++ fltk/ComboBox.h Sun Apr 2 12:07:16 2006 @@ -103,7 +103,7 @@ ComboBox *combo_; }; ComboInput *input_; -#ifdef _WIN32 +#if defined ( _WIN32 ) || defined ( __GNUC__ ) && __GNUC__ < 3 public: #endif static void input_callback_(Widget*,void*);

April 2, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

In article <FCZNR2Ai+lLEFwiV(a)n-cantrell.demon.co.uk>, robert w hall <bobh(a)n-cantrell.demon.co.uk> writes >But, the latest fltk does not compile on the ps2 (...'input_callback...' >is private) - looks like the age of the ps2 base-distribution may be >catching us out? > > but fltk-1.1.7 _does_ compile OK - is it possible to fix the download dpi to run with the earlier version this time? -- robert w hall

April 1, 2006

OSDL Fellowship Fund

by Michal Nowak

Hi Jorge, I don't know if you've heard about 'OSDL Fellowship Fund', which can be found here (http://www.osdl.org/lab_activities/fellowship_fund/) I hope it can help funding your work on Dillo. Check it out. Regards, Michal -- # Michal Nowak # jabber: nowak(a)jabber.cz # irc: #wmii @ irc.oftc.net ---> newman # icq: 170814295

April 1, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jeremy Henty

On Thu, Mar 30, 2006 at 10:30:32PM +0100, Jeremy Henty (ie. me) wrote: > > It breaks http://news.independent.co.uk/ , -rc3 renders it as plain > > text, -rc2 is fine. > > It breaks http://www.slate.com/ too. Aargh! *More* breakage! I've discovered MP3s often start wtih "ID3<lots of whitespace>" so -rc3 guesses they are text/plain . Don't know how to fix this. http://www.nostalgia.com/nf_moreinfo.html?sku=10576 starts with "<!HAS_WEBDNA_TAGS>", again -rc3 guesses text/plain . I can work around this by skipping all leading "<!...>" tags except the "<!DOCTYPE...>". http://www.techworld.com/applications/news/index.cfm?NewsID=5685&inkc=0 starts with a *huge* amount of whitespace and triggers a bug in the content type guesser: it gets a buffer full of whitespace, skips all the way to the end and guesses based on the following garbage in memory. This turns out to be 8 or so binary characters followed by ascii text from a previous buffer. Sometimes the text is part of a previous page, sometimes it contains the message "waiting for the server". -rc3 guesses text/plain . I fixed this bug by adding "if (i==Size) return st;" before doing any guessing - clearly Dillo should not try to guess if it has nothing guess with. I vote against content type guessing unless it can be improved a lot. It just doesn't work well enough. (BTW, I've frequently run Dillo -rcs before and this is the first one that gave me any trouble at all.) Jeremy Henty

April 1, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

In article <$N7zyiApBaLEFw0m(a)n-cantrell.demon.co.uk>, robert w hall <bobh(a)n-cantrell.demon.co.uk> writes >I _hope_ to test on the ps2 over the weekend, when I can get the creaky >box back up proerly >Bob > > >In article <20060330155817.GC29028(a)dillo.org>, Jorge Arellano Cid ><jcid(a)dillo.org> writes >>Hi there! >> >> The new dillo-0.8.6-rc3 tarball is ready for download. Get it >>from: >> >> http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 OK, I can compile this with --disable-dlgui (for this relief much thanks...) But, the latest fltk does not compile on the ps2 (...'input_callback...' is private) - looks like the age of the ps2 base-distribution may be catching us out? -- robert w hall

April 1, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

I _hope_ to test on the ps2 over the weekend, when I can get the creaky box back up proerly Bob In article <20060330155817.GC29028(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes >Hi there! > > The new dillo-0.8.6-rc3 tarball is ready for download. Get it >from: > > http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 > > Finally I decided to include a big patch for the MIME type >detection and its handling. This is an important change in the >way Dillo treats its incoming files (HTTP streams). > > The point: as this release comes with a new downloads GUI, and >downloads are mainly the focus, I disliked the situation where a >Web server "lied" with regard to the Content/Type of a file. > > For instance, www.linuxpackages.net has many packages and a >system of distributed mirrors. Some of these mirrors serve .tgz >files with "text/plain" HTTP-Content/Type labels, with the end >result of Dillo trying to render the .tgz as text instead of >offering a file-save dialog. > > This patch fixes this. > > Now Dillo uses its detected Content/Type instead of the one >sent by the remote server (there's also a bug fix in the >detection code). > > e.g. > > http://www.software-mirror.com/linuxpackages/Slackware-10.2/ > X11/kpacman/kpacman-0.3.3-i486-1ron.tgz > > (all in one line) > > Try it with dillo <= rc2. It will try to render. > > FWIW, the remote server answer begins with: > > HTTP request sent, awaiting response... > HTTP/1.0 200 OK > Date: Wed, 29 Mar 2006 15:53:23 GMT > Server: Apache > Last-Modified: Wed, 12 Oct 2005 11:31:54 GMT > ETag: "262819-28292-f8a5de80" > Accept-Ranges: bytes > Content-Length: 164498 >>>> Content-Type: text/plain > Age: 95 > X-Cache: HIT from sa8.woowy.com > Connection: keep-alive > Length: 164,498 (161K) [text/plain] > 200 OK > > I'm a bit surprised nobody complained about this bug before, >but I guess with the download support being as crude as it was, >it's no wonder only a few people used it. ;-) > > Bottom line: > > PLease test this extensively! > > -- robert w hall

March 31, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Francis Daly

On Thu, Mar 30, 2006 at 11:58:17AM -0400, Jorge Arellano Cid wrote: Hi there, > Finally I decided to include a big patch for the MIME type > detection and its handling. This is an important change in the > way Dillo treats its incoming files (HTTP streams). > Now Dillo uses its detected Content/Type instead of the one > sent by the remote server (there's also a bug fix in the > detection code). I confess, I'm with the "no, no, no" crowd. > http://www.software-mirror.com/linuxpackages/Slackware-10.2/ > X11/kpacman/kpacman-0.3.3-i486-1ron.tgz X11/fbpager/fbpager-0.1.4-i486-1awg.tgz is the same, only a bit smaller at 66k. > Try it with dillo <= rc2. It will try to render. Yes. And it's right to. The content is text/plain, and dillo renders text/plain. After it has rendered, if I want to save it, I can right click and Save page As... and it stores the uncorrupted content. I can then mutter about broken web server admins, but be happy that my client is behaving. (If, for example, it changed the content by "ascii-mode"'ing it before rendering or saving, I'd criticise dillo.) And then I realise that if I want to download something, I should right-click the initial link and Save Link As... and the world is good. Works for all content types, I believe. > I'm a bit surprised nobody complained about this bug before, > but I guess with the download support being as crude as it was, > it's no wonder only a few people used it. ;-) I thought the download support was fine. If I wanted to d/l something, right click. Just like in the other graphical browsers I use. (Or copy link location, and paste into a dedicated downloader. Just like in the other browsers I use.) If I wanted to view something, left click. Just like in the other graphical browsers I use. Not much room for confusion, and not much new learning needed. Any chance of a "--unbreak-me" configure option? f -- Francis Daly francis(a)daoine.org

March 31, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Kelson Vibber

Yeah, I'm seeing problems as well. Putting the character set into the Content-Type header in the form 'text/html; charset=utf-8' is actually recommended by the W3C: http://www.w3.org/International/O-HTTP-charset Some of the problems with the current implementation might be resolved by normalizing the content-type. In general, I'm not a big fan of content sniffing unless it's done in very limited circumstances. Often the server has a reason to use that content-type. The way Mozilla handled this was to only do content sniffing if the server used text/plain. It's more likely that you'll find a server that's sending the default type* than one that's deliberately serving something incorrect.** http://www.mozilla.org/docs/web-developer/mimetypes.html Even then, you have to be careful, as illustrated here: http://diveintomark.org/archives/2004/08/13/safari-content-sniffing It's a text document, properly served as text/plain, that mentions XHTML in the first line. The then-current version of Safari decided to render it as XHTML. * Apache uses a default of text/plain for all files it can't identify. I think this is a bad idea, but it's probably still used for historical reasons. IIS uses application/octet-stream, which doesn't tell you anything, but at least it usually triggers a download instead of trying to display binary data as text. This is one of those rare cases where I think IIS got it right and Apache got it wrong. ** This is also why so many RPM packages are served as RealPlayer files. RealPlayer was the first popular use for the .rpm extension, so lots of servers got configured that way. -- Kelson Vibber www.hyperborea.org

March 30, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Diego Sáenz

I disagree about the check mime feature. RFC2616 section 7.2.1: "If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource" What if a server want(not wrong) to send a html file like text/plain or application/ocet-stream? A link about this topic http://ppewww.ph.gla.ac.uk/%7Eflavell/www/content-type.html Maybe a mail to the bad servers help to correct content-type. DarkSpirit. El Thu, 30 Mar 2006 11:58:17 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi there! > > The new dillo-0.8.6-rc3 tarball is ready for download. Get it > from: > > http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 > > Finally I decided to include a big patch for the MIME type > detection and its handling. This is an important change in the > way Dillo treats its incoming files (HTTP streams). > > The point: as this release comes with a new downloads GUI, and > downloads are mainly the focus, I disliked the situation where a > Web server "lied" with regard to the Content/Type of a file. > > For instance, www.linuxpackages.net has many packages and a > system of distributed mirrors. Some of these mirrors serve .tgz > files with "text/plain" HTTP-Content/Type labels, with the end > result of Dillo trying to render the .tgz as text instead of > offering a file-save dialog. > > This patch fixes this. > > Now Dillo uses its detected Content/Type instead of the one > sent by the remote server (there's also a bug fix in the > detection code). > > e.g. > > http://www.software-mirror.com/linuxpackages/Slackware-10.2/ > X11/kpacman/kpacman-0.3.3-i486-1ron.tgz > > (all in one line) > > Try it with dillo <= rc2. It will try to render. > > FWIW, the remote server answer begins with: > > HTTP request sent, awaiting response... > HTTP/1.0 200 OK > Date: Wed, 29 Mar 2006 15:53:23 GMT > Server: Apache > Last-Modified: Wed, 12 Oct 2005 11:31:54 GMT > ETag: "262819-28292-f8a5de80" > Accept-Ranges: bytes > Content-Length: 164498 > >>> Content-Type: text/plain > Age: 95 > X-Cache: HIT from sa8.woowy.com > Connection: keep-alive > Length: 164,498 (161K) [text/plain] > 200 OK > > I'm a bit surprised nobody complained about this bug before, > but I guess with the download support being as crude as it was, > it's no wonder only a few people used it. ;-) > > Bottom line: > > PLease test this extensively! > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 30, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jeremy Henty

On Thu, Mar 30, 2006 at 06:45:16PM +0100, Jeremy Henty (ie. me) wrote: > It breaks http://news.independent.co.uk/ , -rc3 renders it as plain > text, -rc2 is fine. It breaks http://www.slate.com/ too. It's a combination of two factors: these sites report the Content-type as "text/html;<extra_crud>" instead of "text/html", and they insert text before the HTML (http://news.independent.co.uk/ has an XML header and http://www.slate.com/ has an HTML comment). Sites with extra text before the HTML hit a bug in Dillo's content type guesser; it doesn't skip that text, so it doesn't see the HTML, so it guesses "text/plain" instead. This bug is *almost* completely masked by a workaround: if the server says "text/html" and Dillo guesses "text/plain" then Dillo assumes it's got tag soup and changes it's mind to "text/html". But if the server says "text/html;<extra_crud>" then Dillo doesn't even recognise that content type so it defaults to going along with it's original guess. I've hacked my copy of -rc3 so that it's content type guesser skips leading XML headers and HTML comments. Let's see if that's enough! Regards, Jeremy Henty

March 30, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jeremy Henty

> PLease test this extensively! It breaks http://news.independent.co.uk/ , -rc3 renders it as plain text, -rc2 is fine. To be honest, I'm dubious about Dillo doing this. I thought breaking the browser to work around broken servers was the sort of thing Dillo strove to avoid. I realise that strict compliance to all standards is infeasible due to the crappiness of teh Internets, but are you *sure* this won't cause more problems than it solves? It's not a good sign that I found a breakage literally within 15 seconds of using this -rc . And I have bad memories of wrestling at work with IE getting the MIME type wrong and refusing to listen to our server's correct MIME header. Was there any discussion of this? I searched the mail archive for "mime" on the web site and found nothing relevant. I don't want to be inflammatory; I am a great Dillo fan. But I'm currently uncomfortable with Dillo doing this. Other Dillo useres are welcome to try and comfort me! (OK, I've done a few more minute's intensive surfing and nothing else has broken, so maybe I was just unlucky. It's still sad it breaks The Independent. The top of the page is: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-UK" > In case it's not apparent, those lines are terminated with Ctrl-M's. Does that explain anything?) Regards, Jeremy Henty

March 30, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2: bug in Html_parse_entity

by Jorge Arellano Cid

Hi Matthias! Hope you're doing well there in Munich. :-) On Tue, Mar 28, 2006 at 09:18:47PM +0200, Matthias Franz wrote: > Hi Jorge, > > I have found the following small problem in html.c: > > the comparison of HTML versions in Html_parse_entity does not work, > apparently because of floating point roundoff errors: On my machine > (i386, Debian Sarge, libc6), the comparison (lines 1016ff) > > if ((html->DocType == DT_HTML && html->DocTypeVersion == 4.01) || > html->DocType == DT_XHTML) > MSG_HTML("undefined character entity '%s'\n", tok); > > is never triggered for HTML 4.01. In fact, html->DocTypeVersion - 4.01 > has the value 2.288818e-07. Currently this is the only place where such > a comparison is used, but I guess this might change in future. I just commited a patch to the CVS for this. Please test it and send some feedback. Note: this is not in rc3. I decided to put rc3 up to have the big patch tested while I work on this other small bugs. -- Cheers Jorge.-

March 30, 2006

dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi there! The new dillo-0.8.6-rc3 tarball is ready for download. Get it from: http://www.dillo.org/download/dillo-0.8.6-rc3.tar.bz2 Finally I decided to include a big patch for the MIME type detection and its handling. This is an important change in the way Dillo treats its incoming files (HTTP streams). The point: as this release comes with a new downloads GUI, and downloads are mainly the focus, I disliked the situation where a Web server "lied" with regard to the Content/Type of a file. For instance, www.linuxpackages.net has many packages and a system of distributed mirrors. Some of these mirrors serve .tgz files with "text/plain" HTTP-Content/Type labels, with the end result of Dillo trying to render the .tgz as text instead of offering a file-save dialog. This patch fixes this. Now Dillo uses its detected Content/Type instead of the one sent by the remote server (there's also a bug fix in the detection code). e.g. http://www.software-mirror.com/linuxpackages/Slackware-10.2/ X11/kpacman/kpacman-0.3.3-i486-1ron.tgz (all in one line) Try it with dillo <= rc2. It will try to render. FWIW, the remote server answer begins with: HTTP request sent, awaiting response... HTTP/1.0 200 OK Date: Wed, 29 Mar 2006 15:53:23 GMT Server: Apache Last-Modified: Wed, 12 Oct 2005 11:31:54 GMT ETag: "262819-28292-f8a5de80" Accept-Ranges: bytes Content-Length: 164498 >>> Content-Type: text/plain Age: 95 X-Cache: HIT from sa8.woowy.com Connection: keep-alive Length: 164,498 (161K) [text/plain] 200 OK I'm a bit surprised nobody complained about this bug before, but I guess with the download support being as crude as it was, it's no wonder only a few people used it. ;-) Bottom line: PLease test this extensively! -- Cheers Jorge.-

March 30, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > OK, here's a patch for this type of log. Please test it and > tell me how it works. Works. Thanks! > I'm considering other minor patches before uploading rc3, so > your testing feedback is welcomed in the meanwhile. You're welcome. I'll check out rc3 as soon as it's available.

March 29, 2006

CVS and rc3

by Jorge Arellano Cid

Hi there, While I review/make other patches that may go in rc3, the CVS already has the patch for downloads and for handling buggy pages with multiple BODY and HTML elements in a page. e.g. http://www.commondreams.org/headlines06/0324-07.htm BTW, I'm taking some more time with the 0.8.6-rc process because I really want this to be the last GTK1-based dillo (at least by me ;). Any maintainer volunteer for this branch? -- Cheers Jorge.-

March 29, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2

by Jorge Arellano Cid

Hi Thomas-Martin, On Tue, Mar 28, 2006 at 08:34:30PM +0200, Thomas-Martin Seck wrote: > > > 2) wget is a bit too chatty - when I download a large file (e.g. > > > <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), > > > the log shown when hovering over the file name field is filled with > > > wget's process entries (10000 k ....\n10050 k .... and so on). > > > > This is supposed to be trimmed out of the log. Please send me a > > small verbatim sample of wget's output in your system to fix it. > > OK, this is with wget 1.10.2 (installed from FreeBSD ports) from a > resumed download via my local proxy: > > --20:31:18-- http://www.kleptones.com/music/Detroit/detroit_burn.zip > => `detroit_burn.zip' > Resolving proxy.tmseck.homedns.org... 192.168.1.1 > Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. > Proxy request sent, awaiting response... 206 Partial Content > Length: 86,987,351 (83M), 60,961,559 (58M) remaining [application/zip] > > [ skipping 25400K ] > 25400K ,,,,,,,,,, ,,,,,..... .......... .......... .......... 29% 40,12 KB/s > 25450K .......... .......... .......... .......... .......... 30% 119,85 KB/s > 25500K .......... .......... .......... .......... .......... 30% 422,65 KB/s > 25550K .......... .......... .......... .......... .......... 30% 240,61 KB/s > 25600K .......... .......... .......... .......... .......... 30% 273,91 KB/s > 25650K .......... .......... .......... .......... .......... 30% 238,91 KB/s > 25700K .......... .......... .......... .......... .......... 30% 313,50 KB/s OK, here's a patch for this type of log. Please test it and tell me how it works. I'm considering other minor patches before uploading rc3, so your testing feedback is welcomed in the meanwhile. -- Cheers Jorge.-

March 29, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2: bug in Html_parse_entity

by Matthias Franz

Hi Jorge, I have found the following small problem in html.c: the comparison of HTML versions in Html_parse_entity does not work, apparently because of floating point roundoff errors: On my machine (i386, Debian Sarge, libc6), the comparison (lines 1016ff) if ((html->DocType == DT_HTML && html->DocTypeVersion == 4.01) || html->DocType == DT_XHTML) MSG_HTML("undefined character entity '%s'\n", tok); is never triggered for HTML 4.01. In fact, html->DocTypeVersion - 4.01 has the value 2.288818e-07. Currently this is the only place where such a comparison is used, but I guess this might change in future. Al the best, -- Matthias Franz

March 28, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > Good! > > I'm glad fltk2 is working without hassled on the FreeBSDs. Hey, BSD is not that exotic! In fact I have been tracking fltk2 snapshots locally on a monthly basis and they all worked (well, they compiled) with the notable exception of the latest one - which does not compile :/ I hope this will sort itself out, though. > > The fltk2 port for FreeBSD is upcoming; I am applying some final touches > > and will submit a "new port request" within the next days. > > Do you mean to have the new fltk2 port "in place" before > dillo-0.8.6? This depends on how fast you are with releasing dillo-0.8.6 :) I hope to get the port out this week but it takes a "ports committer" to actually get it into the tree so I cannot say when exactly fltk2 will be available via FreeBSD ports. The dillo 0.8.6 update will not ship with dlgui enabled by default so there is no hard dependency on fltk2 that could stop the dillo port from being updated. I will, however, disable threaded DNS on FreeBSD 4.x since some resolver functions are explicitly described as not thread-safe there. On 5.x and up, thread support is no longer an issue to worry about.

March 28, 2006

Re: [Dillo-dev] dillo-0.8.6-rc2

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > On Sun, Mar 26, 2006 at 08:17:04PM +0200, Thomas-Martin Seck wrote: > > > > Two minor nits with the download gui: > > > > 1) The "Rename" button shown in the dialogue that appears when one tries > > to overwrite an existing file is to small for the text "Rename" and > > the "this is the default button hook" symbol - the "R" of "Rename" is > > painted on the left border of said button. This may be a local font > > size issue or an FLTK problem, though. > > FLTK problem. > > The message dialog used there is an fltk2-internal function. > > Maybe I could let them know... Only if you or someone else can easily reproduce this. > > 2) wget is a bit too chatty - when I download a large file (e.g. > > <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), > > the log shown when hovering over the file name field is filled with > > wget's process entries (10000 k ....\n10050 k .... and so on). > > This is supposed to be trimmed out of the log. Please send me a > small verbatim sample of wget's output in your system to fix it. OK, this is with wget 1.10.2 (installed from FreeBSD ports) from a resumed download via my local proxy: --20:31:18-- http://www.kleptones.com/music/Detroit/detroit_burn.zip => `detroit_burn.zip' Resolving proxy.tmseck.homedns.org... 192.168.1.1 Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. Proxy request sent, awaiting response... 206 Partial Content Length: 86,987,351 (83M), 60,961,559 (58M) remaining [application/zip] [ skipping 25400K ] 25400K ,,,,,,,,,, ,,,,,..... .......... .......... .......... 29% 40,12 KB/s 25450K .......... .......... .......... .......... .......... 30% 119,85 KB/s 25500K .......... .......... .......... .......... .......... 30% 422,65 KB/s 25550K .......... .......... .......... .......... .......... 30% 240,61 KB/s 25600K .......... .......... .......... .......... .......... 30% 273,91 KB/s 25650K .......... .......... .......... .......... .......... 30% 238,91 KB/s 25700K .......... .......... .......... .......... .......... 30% 313,50 KB/s Smaller downloads look like this: --20:32:31-- http://www.kleptones.com/music/Detroit/The%20Kleptones%20-%20From%20Detroit… => `The Kleptones - From Detroit to JA - 01 - Fox Intro.mp3' Resolving proxy.tmseck.homedns.org... 192.168.1.1 Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. Proxy request sent, awaiting response... 200 OK Length: 3,066,271 (2,9M) [audio/mpeg] 0K .......... .......... .......... .......... .......... 1% 48,30 KB/s 50K .......... .......... .......... .......... .......... 3% 207,92 KB/s 100K .......... .......... .......... .......... .......... 5% 257,80 KB/s 150K .......... .......... .......... .......... .......... 6% 249,50 KB/s 200K .......... .......... .......... .......... .......... 8% 270,76 KB/s 250K .......... .......... .......... .......... .......... 10% 246,22 KB/s 300K .......... .......... .......... .......... .......... 11% 237,05 KB/s 350K .......... .......... .......... .......... .......... 13% 407,15 KB/s

March 28, 2006

Re: [Dillo-dev] Re: rc2 compile errors

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > On Tue, Mar 28, 2006 at 10:15:05AM +0200, pete(a)teamlupus.hu wrote: > > hi, > > > > i tried and it won't compile unless fltk download gui is not disabled > > From make output I assume you mean "until fltk download gui > _is_ disabled". > > > (after that it compiles and haven't crashed in a few minutes ) > > > > Dillo is cool. > > :-) > > As Thomas-Martin wrote: > > > Note to everyone who wants to use the fltk2 port on FreeBSD 4: fltk2 > > needs gcc 3.x, so that port will include a build dependency on gcc 3.4. > > You're using gcc version 4.0.2. This may be the cause. Maybe it is; maybe it's just a CPPFLAGS issue i.e. the compiler misses some includes (since the OP seems to run linux in Hungarian locale I cannot comment on this one since I do not understand the error messages :)). I can confirm that dillo+fltk2 compiles with g++ 3.4.4 and g++ from a gcc 3.4.6 svn snapshot on FreeBSD 4, 5 and 6. I did not test gcc 4.x, since FreeBSD 5 and up still use gcc 3.4 as the system compiler. The issue I was adressing with my post is that you need to install gcc 3.4 before in order to build fltk2 and dillo+dlgui. Since bootstrapping gcc takes quite some time, this may be a problem for those who are building dillo on slower machines. So I thought I'd give a word of warning in advance.

March 28, 2006

Re: rc2 compile errors

by Jorge Arellano Cid

Hi, On Tue, Mar 28, 2006 at 10:15:05AM +0200, pete(a)teamlupus.hu wrote: > hi, > > i tried and it won't compile unless fltk download gui is not disabled From make output I assume you mean "until fltk download gui _is_ disabled". > (after that it compiles and haven't crashed in a few minutes ) > > Dillo is cool. :-) As Thomas-Martin wrote: > Note to everyone who wants to use the fltk2 port on FreeBSD 4: fltk2 > needs gcc 3.x, so that port will include a build dependency on gcc 3.4. You're using gcc version 4.0.2. This may be the cause. BTW: are you subscribed to dillo-dev? I'm answering to dillo-dev and to you because you wrote me directly. > > ===================== > > Linux frugalwork 2.6.15-fw2 #1 SMP PREEMPT Fri Feb 10 21:07:57 CET 2006 i686 > athlon-4 i386 GNU/Linux > > ===================== > > pete@frugalwork:~/Desktop/dev/dillo-0.8.6-rc2$ gcc -v > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ../gcc-4.0.2/configure --prefix=/usr --enable-shared > --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit > Thread model: posix > gcc version 4.0.2 > > ===================== > > Making all in dpi > make[2]: Entering directory > `/home/pete-frugalwork/Desktop/dev/dillo-0.8.6-rc2/dpi' > if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include > -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 -MT downloads.o -MD > -MP -MF ".deps/dow > nloads.Tpo" -c -o downloads.o downloads.cc; \ > then mv -f ".deps/downloads.Tpo" ".deps/downloads.Po"; else rm -f > ".deps/downloads.Tpo"; exit 1; fi > downloads.cc:34:22: error: fltk/run.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:35:25: error: fltk/Window.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:36:25: error: fltk/Widget.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:37:25: error: fltk/damage.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:38:22: error: fltk/Box.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:39:23: error: fltk/draw.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:40:34: error: fltk/HighlightButton.h: Nincs ilyen fájl vagy > könyvtár > downloads.cc:41:30: error: fltk/PackedGroup.h: Nincs ilyen fájl vagy > könyvtár > downloads.cc:42:30: error: fltk/ScrollGroup.h: Nincs ilyen fájl vagy > könyvtár > downloads.cc:43:22: error: fltk/ask.h: Nincs ilyen fájl vagy könyvtár > downloads.cc:44:31: error: fltk/file_chooser.h: Nincs ilyen fájl vagy > könyvtár > downloads.cc:49: error: 'fltk' is not a namespace-name > downloads.cc:49: error: expected namespace-name before ';' token > downloads.cc:75: error: expected class-name before '{' token > downloads.cc:83: error: 'Color' does not name a type > downloads.cc:102: error: 'Color' has not been declared > downloads.cc:103: error: 'Color' does not name a type > downloads.cc: In member function 'void ProgressBar::step(double)': > downloads.cc:90: error: 'redraw' was not declared in this scope > downloads.cc: In member function 'void ProgressBar::position(double)': > downloads.cc:98: error: 'redraw' was not declared in this scope > downloads.cc: In member function 'void ProgressBar::message(char*)': > downloads.cc:100: error: 'redraw' was not declared in this scope > downloads.cc: In member function 'void ProgressBar::text_color(int)': > downloads.cc:102: error: 'mTextColor' was not declared in this scope > downloads.cc: At global scope: > downloads.cc:128: error: ISO C++ forbids declaration of 'Group' with no type > downloads.cc:128: error: expected ';' before '*' token > downloads.cc:130: error: ISO C++ forbids declaration of 'HighlightButton' > with no type > downloads.cc:130: error: expected ';' before '*' token > downloads.cc:131: error: ISO C++ forbids declaration of 'Widget' with no > type > downloads.cc:131: error: expected ';' before '*' token > downloads.cc:147: error: ISO C++ forbids declaration of 'Widget' with no > type > downloads.cc:147: error: expected ';' before '*' token > downloads.cc:148: error: expected `;' before 'int' > ===================== > > ---- > Péter > -- Cheers Jorge.-

March 28, 2006