March 2006 - Dillo-dev - lists.mailman3.com

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