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.-
On Wed, Apr 05, 2006 at 06:52:22PM -0400, Jorge Arellano Cid wrote:
Works correctly with all the problem pages I found with -rc3. Haven't used it on MP3s yet. Cheers, Jeremy Henty
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
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.-
In article <4436969B.8080202@pobox.com>, Kelson Vibber <kelson@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
* Jorge Arellano Cid (jcid@dillo.org):
The new rc4 tarball is ready:
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?
On Sun, Apr 09, 2006 at 02:34:15PM +0200, Thomas-Martin Seck wrote:
* Jorge Arellano Cid (jcid@dillo.org):
The new rc4 tarball is ready:
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.-
* Thomas-Martin Seck (tmseck-lists@netcologne.de):
* Jorge Arellano Cid (jcid@dillo.org):
The new rc4 tarball is ready:
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.)
participants (5)
-
Jeremy Henty -
Jorge Arellano Cid -
Kelson Vibber -
robert w hall -
Thomas-Martin Seck