July 2005 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]viewing non-web files

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > That dpi must support mailcap because every linux distro and unix flavour > have it configured by default and some user too. It must use file if > unknown the mime type, but must use the mime type of the http headers if > possible. It needs to be configurable by the user, to display html pages to > ask the user if there are multiple acctions posible, available to call > other DPIs to manage some mime types, but all this can be add later when > basic funcionality is done. I'm also voting for having external mime support directly in dillo. if there is a coordinated work is done, there is one prob with the avail external patch: even when passed though the file.dpi (eg. file://myacro.pdf) a new temp file is created and the external mime-viewer is called on this. there are several problems: 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs 2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise just my 2 cents, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCymEUw6IyDgGSsNIRAr56AJ475U6rGOKGlxPrWaY5MhNm1EL9kwCeLrj7 iq1ZMcHP/feMV6ugh2kyrBM= =V1RP -----END PGP SIGNATURE-----

July 5, 2005

Re: [Dillo-dev]Meta-refresh warning

by Roberto A. Foglietta

Glyn Kennington wrote: > While using dillo to check some pages for AnyBrowser-friendliness, I've > encountered the warning inserted whenever a <meta http-equiv="refresh" > ...> tag is used. I interpreted this as meaning that the HTML I'd > written was in some way wrong, and I should find another way to achieve > the same effect. > > The warning says: > > This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 > SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it. > > I checked that part of the HTML spec to see exactly what it said, and > whether it suggested any better alternatives. However, all that section > has to say about the use of "refresh" is: > > ( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 ) > > Note. Some user agents support the use of META to refresh the current > page after a specified number of seconds, with the option of replacing > it by a different URI. Authors should not use this technique to forward > users to different pages, as this makes the page inaccessible to some > users. Instead, automatic page forwarding should be done using > server-side redirects. > > My understanding of that paragraph is that it's only recommending > against redirection, in which the refresh tag specifies that a different > page should be loaded after the timeout. It might additionally mean > that it's only discouraged for "instant" (ie. delay=0) redirection. > > OTOH, refreshing the same page (which is what I'm trying to do with the > page that I'm writing) should be OK. In this case, shouldn't dillo only > complain if the "content" part of the tag contains a "URL=" (even if it > won't handle the refresh without the aid of the meta-refresh patch)? > > I can write the necessary trivial patch to insert such a check if people > agree that it's The Right Thing, but I thought I'd better check that > I've interpreted the spec properly (and am reading the right bit of it) > before I do so. > May be you can modify my patch, as far I know it works with 0.8.5 http://www.roberto.foglietta.name/pub/dillo/ It able to refresh AND redirect, but only if -r option is specified in command line. May be you can modify it to refresh ALWAYS and use -r option ONLY for redirect when time is more than the specified offset -r <seconds> Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Diego Sáenz

Daniel, Matthias. Why not to cordinate effors? What about a group to bring this feature to "official" dillo? I am not a core developer and i unknown what core developers can think that is needed to include such feature, but i can imagine one: Add the minimal code to dillo. This can be done with a dpi, a filter dpi can be enough, like xproto for example. Dillo only needs to include a pair of lines to send a dpi command. To write a dpi is easy, i can help if it is needed. Some personal opinions more, but less important ones. That dpi must support mailcap because every linux distro and unix flavour have it configured by default and some user too. It must use file if unknown the mime type, but must use the mime type of the http headers if possible. It needs to be configurable by the user, to display html pages to ask the user if there are multiple acctions posible, available to call other DPIs to manage some mime types, but all this can be add later when basic funcionality is done. Diego Sáenz / DarkSpirit El Mon, 4 Jul 2005 19:55:48 +0200 Matthias Franz <matthias.franz(a)ujf-grenoble.fr> escribio: > On Mon, Jul 04, 2005 at 07:53:40AM +0000, Daniel C. Bastos wrote: > > quick patch to get dillo to let me quickly view PDF files > [...] > > I wanted to drop you guys this message to tell you guys that there's > > one user who would like such feature in dillo > > Hi Daniel, > > I've written such a patch, see my posting > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html > > The patch is for Dillo 0.8.4, but it also works for 0.8.5. Well - almost. > Apparently, the src/Makefile is wrong. The file external.c is not compiled, > and external.o is not used for linking dillo. It's easy to change this by > hand, but I haven't had time yet to fix the patch. Maybe it's related to > the new version 1.9 of automake (which I haven't installed). > > Maybe someone could step in and fix the patch? Thanks in advance, > -- > Matthias Franz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Matthias Franz

On Mon, Jul 04, 2005 at 07:53:40AM +0000, Daniel C. Bastos wrote: > quick patch to get dillo to let me quickly view PDF files [...] > I wanted to drop you guys this message to tell you guys that there's > one user who would like such feature in dillo Hi Daniel, I've written such a patch, see my posting http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html The patch is for Dillo 0.8.4, but it also works for 0.8.5. Well - almost. Apparently, the src/Makefile is wrong. The file external.c is not compiled, and external.o is not used for linking dillo. It's easy to change this by hand, but I haven't had time yet to fix the patch. Maybe it's related to the new version 1.9 of automake (which I haven't installed). Maybe someone could step in and fix the patch? Thanks in advance, -- Matthias Franz

July 4, 2005

[Dillo-dev]viewing non-web files, thanks, etc

by Daniel C. Bastos

I'm a dillo user, not a developer, but I sat down one day to write a quick patch to get dillo to let me quickly view PDF files because I read lots of them from the web. So I wrote a program called quick and then I wrote a patch to get dillo to call quick when it's a file that quick can open. I'm happy with the benefit, but this is not a patch for dillo, it's just a hack to get me happy (I didn't use glib, for example.) I wanted to drop you guys this message to tell you guys that there's one user who would like such feature in dillo and I should perhaps ask you guys how you would build such feature in dillo if you were to sit down today and do it. Who knows? I could do it myself, if it won't be too complicated. I also wanted to say thanks. I think the software is great. http://math.utoledo.edu/~dbastos/files/patch/patch_dillo_cache.c http://math.utoledo.edu/~dbastos/files/quick-0.1.tar.gz

July 4, 2005

Re: [Dillo-dev]cookies dpi over https and dpi framework

by Diego Sáenz

Hello, i have found that the problem was in https dpi. Under some circunstances, self signed certificate and formated in some way, the https dpi died. I send a patch to fix it. The patch is for dillo 0.8.5 but surely it works in previous versions, only touches dpi/https.c, it works with or without cookies.dpi patch, whitout cokies.dpi patch only the first dillo have cookies. I send a this mail with cc to the list to make it,the new(and the fix), public so the people can test it ASAP. Diego Sáenz/DarkSpirit. 8<--------------------CUT HERE------------------>8 diff -pru dillo-0.8.5-DIRTY/dpi/https.c dillo-0.8.5-WORK/dpi/https.c --- dillo-0.8.5-DIRTY/dpi/https.c 2005-07-03 23:25:06.000000000 +0200 +++ dillo-0.8.5-WORK/dpi/https.c 2005-07-03 23:29:23.000000000 +0200 @@ -331,6 +331,7 @@ static int handle_certificate_problem(SS int retval = -1; long st; char buf[4096]; + char * cn, * cn_end; X509 * remote_cert; @@ -363,12 +364,16 @@ static int handle_certificate_problem(SS case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: /*Either self signed and untrusted*/ /*Extract CN from certificate name information*/ - strncpy(buf, (strstr(remote_cert->name, "/CN=") + 4), - (size_t)(strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 4)); + cn = strstr(remote_cert->name, "/CN=") + 4; + if (cn == NULL) break; + + if ((cn_end = strstr(cn, "/")) == NULL ) cn_end = cn + strlen(cn); + + strncpy(buf, cn, (size_t) (cn_end - cn)); + /*Add terminating NULL*/ - buf[strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 3] = 0; + buf[cn_end - cn] = 0; + sock_handler_printf(sh, 1, "<dpi cmd='dialog' msg='%s%s' alt1='%s' alt2='%s' alt3='%s'>", "The remote certificate is self-signed and untrusted.\n" 8<----------------------CUT HERE------------------------>8 El Tue, 28 Jun 2005 00:13:24 +0200 Jorgen Viksell <jviksell(a)dillo.org> escribio: > OK, now it's up at: > https://www.dillo.org/~jviksell/test.php > http://www.dillo.org/~jviksell/test.php > > It sends four secure cookies and four unsecure. > > Cheers, > Jörgen

July 3, 2005

[Dillo-dev]Meta-refresh warning

by Glyn Kennington

While using dillo to check some pages for AnyBrowser-friendliness, I've encountered the warning inserted whenever a <meta http-equiv="refresh" ...> tag is used. I interpreted this as meaning that the HTML I'd written was in some way wrong, and I should find another way to achieve the same effect. The warning says: This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it. I checked that part of the HTML spec to see exactly what it said, and whether it suggested any better alternatives. However, all that section has to say about the use of "refresh" is: ( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 ) Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should not use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects. My understanding of that paragraph is that it's only recommending against redirection, in which the refresh tag specifies that a different page should be loaded after the timeout. It might additionally mean that it's only discouraged for "instant" (ie. delay=0) redirection. OTOH, refreshing the same page (which is what I'm trying to do with the page that I'm writing) should be OK. In this case, shouldn't dillo only complain if the "content" part of the tag contains a "URL=" (even if it won't handle the refresh without the aid of the meta-refresh patch)? I can write the necessary trivial patch to insert such a check if people agree that it's The Right Thing, but I thought I'd better check that I've interpreted the spec properly (and am reading the right bit of it) before I do so. Glyn

July 3, 2005

Re: [Dillo-dev]dillo on sparc64

by Damien COUDERC

Hi, i still have problems with latest release of dillo on sparc64. I have no more time to waste on this problem so i'm stopping my porting effort for OpenBSD. If you want to fix the problem just look at the following: $ dillo & [1] 5810 $ Nav_open_url: Url=>about:splash< Nav_open_url: Url=>dpi:/bm/< dpi_socket_dir.c:62: tst_dir: access : No such file or directory - /tmp/mips-uonqpe/ debug_msg - init_sockdir: The socket directory /tmp/mips-uonqpe does not exist or is not a directory dpid started Capi_dpi_conn_timeout:: try 1 main.c:154: get_command: dpid tag is NULL : main.c:328: main: get_command failed : bookmarks.dpi (v.13): accepting connections... [fopen]: No such file or directory Dpi_parse_token: [<ÐÐÐÐÐÐÐÐÐÐÐÐÐÐÐsend_page' url='dpi:/bm/'>] [sock_handler_write]: Broken pipe [1] + Segmentation fault dillo (core dumped) Good luck for your project, Damien

July 3, 2005

Re: [Dillo-dev]small question about TagInfo in html.c

by Jorge Arellano Cid

On Sat, Jul 02, 2005 at 09:17:20PM +0200, Wim De Smet wrote: > On 7/2/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > On Sat, Jul 02, 2005 at 02:57:49PM +0200, Wim De Smet wrote: > > > Hey, > > > > > > What exactly do the EndTag en TagLevel fields in the TagInfo struct > > > stand for? I was going to add the "q" function but I'm not sure what I > > > should fill in here. (and it wasn't directly clear from the otherwise > > > excellent src docs). > > > > EndTag holds whether the end tag of the HTML element is > > "Required", "Optional" or "Forbidden" as of the HTML 4.01 SPEC. > > > > TagLevel is a number that is used to heuristically parse bad > > HTML (it overrides the HTML SPEC a bit). The comment over > > Html_tag_cleanup_at_close() explains this. > > > > In a nutshell, a higher TagLevel allows the closing element's > > tag to close intermediate open tags, in the parsing stack, with > > lower TagLevel. > > > > Just use 2 as the value! :-) > > Okay then. But does this make it possible that the function for the > close tag is then called twice? The way I'm trying to get the q to > render now is just adding in an open tag and a close tag function and > calling a_Dw_page_add_text from both. The problem being that the text > seems to be added twice at the end. Related, I presumed that for > add_text I have to alloc the string but not dealloc it. Is this > correct? Call a_Dw_page_add_text from open tag only. Close tag is mainly for cleanups. > Still mucking about a bit. ;-) Look at some other simple elements. There're plenty of examples in html.c. -- Cheers Jorge.-

July 2, 2005

Re: [Dillo-dev]small question about TagInfo in html.c

by Wim De Smet

On 7/2/05, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Sat, Jul 02, 2005 at 02:57:49PM +0200, Wim De Smet wrote: > > Hey, > > > > What exactly do the EndTag en TagLevel fields in the TagInfo struct > > stand for? I was going to add the "q" function but I'm not sure what I > > should fill in here. (and it wasn't directly clear from the otherwise > > excellent src docs). > > EndTag holds whether the end tag of the HTML element is > "Required", "Optional" or "Forbidden" as of the HTML 4.01 SPEC. > > TagLevel is a number that is used to heuristically parse bad > HTML (it overrides the HTML SPEC a bit). The comment over > Html_tag_cleanup_at_close() explains this. > > In a nutshell, a higher TagLevel allows the closing element's > tag to close intermediate open tags, in the parsing stack, with > lower TagLevel. > > Just use 2 as the value! :-) Okay then. But does this make it possible that the function for the close tag is then called twice? The way I'm trying to get the q to render now is just adding in an open tag and a close tag function and calling a_Dw_page_add_text from both. The problem being that the text seems to be added twice at the end. Related, I presumed that for add_text I have to alloc the string but not dealloc it. Is this correct? Still mucking about a bit. ;-) greets, Wim

July 2, 2005