- Dillo-dev - lists.mailman3.com

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