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.-
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
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
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
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.-
On 4/2/06, Jorge Arellano Cid <jcid@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
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
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@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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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@daoine.org
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@dillo.org>, Jorge Arellano Cid <jcid@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
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@dillo.org>, Jorge Arellano Cid <jcid@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
In article <$N7zyiApBaLEFw0m@n-cantrell.demon.co.uk>, robert w hall <bobh@n-cantrell.demon.co.uk> writes 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
In article <FCZNR2Ai+lLEFwiV@n-cantrell.demon.co.uk>, robert w hall <bobh@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
Hi, On Sat, Apr 01, 2006 at 02:13:05PM +0100, robert w hall wrote:
In article <FCZNR2Ai+lLEFwiV@n-cantrell.demon.co.uk>, robert w hall <bobh@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.-
* robert w hall (bobh@n-cantrell.demon.co.uk):
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@dillo.org>, Jorge Arellano Cid <jcid@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
In article <$N7zyiApBaLEFw0m@n-cantrell.demon.co.uk>, robert w hall <bobh@n-cantrell.demon.co.uk> writes 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*);
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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-- Cheers Jorge.-
In article <20060402101918.GA1052@hardy.tmseck.homedns.org>, Thomas- Martin Seck <tmseck-lists@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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-- 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
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.-
In article <20060406120500.GF13477@dillo.org>, Jorge Arellano Cid <jcid@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
* Jorge Arellano Cid (jcid@dillo.org):
Hi there!
The new dillo-0.8.6-rc3 tarball is ready for download. Get it from:
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?
participants (8)
-
Diego Sáenz -
Francis Daly -
Jeremy Henty -
Jorge Arellano Cid -
Kelly Price -
Kelson Vibber -
robert w hall -
Thomas-Martin Seck