- Dillo-dev - lists.mailman3.com

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

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

by Jorge Arellano Cid

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! :-) -- Cheers Jorge.-

July 2, 2005

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

by Wim De Smet

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). TIA, Wim

July 2, 2005

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

by Diego Sáenz

Hello, now that i have some free time i want to test the cookies dpi over https like Jorge suggested. I need the server so i ask to the webmaster if he can mount some https pages with cookies for the test, like Jorge suggested too. About other things and thinking about the future, i have some ideas about DPI framework and DPIs that can be useful, maybe. Register and init DPIs I think that the way that gives more adventages is to let dpid manage this using dpidrc to store the list of available DPIs(updated each time dpid is runned with the installed DPIs in the system and in the HOME/.dillo/dpi directory), and the metadata about DPIs: mime types or protocol that manages that DPI, menu entries or buttons that DPIs need and the more important if a user wants use(enabled) that DPI or not(disabled) dpidc need new commands (enable, disable, list DPIs) and individual register of DPIs(dpidc register directory/where/the/new/DPI/is) When a new DPI is register dpid run the DPI and ask the DPI metadata which a new DPI command(<dpi cmd='give_metadata'> ?) and the DPI returns the metadata in a text key-value format, for example a dpi that converts rtf and pdf files to html can send postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf (with the right mime type of course) After this dpid stores the metadata in dpidrc file. For example: DPI=rtf_pdf_viewer state=enabled or disabled or ... postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf And now three ways to get the new metadata in dillo or the DPIs that understand them: 1) The pasive solution. when a DPI start it read the dpidrc searching the metadata that it understand. (A DPI that manages mime types, so dillo do not need to do it, can make a list with the name and mimes that understand each DPI) 2) Active, but silly one. Dpid re-send the metadata to each other DPI, with a new DPI command, and each DPI redo his internal state with the metadata it understand. This is the worst solution because dpid need to run all DPIs to be sure that metadata arrives to the right DPI. 3) The complex and flexible solution, my prefered one. There is a key-value(send_me) in the DPIs metadata to register keys of metadatas. Dpid understand this key(send_me) and have a internal list to send the metadatas to the right DPI. If a DPI send a key registered with the send_me key while registering, dpid sends the change to the DPI that registered that key so it can update its internal data, caches, whatever. Example: A mime DPI manages the files with mime types unknows to dillo. When it register send this metadata and is stored in dpidrc like part of its metadata send_me=mime_understand Then after the rtf_pdf_viewer DPI is registered, and if it is enabled, dpid send to the mime DPI the DPI=rtf_pdf_viewer mime_understand=text/x-rtf,text/x-pdf and mime DPI updates its state so it can call rtf_pdf_viewer when find a rtf or pdf file. Pros: - It is so flexible that new keys and resources can be used by new DPIs while dpid, or even dillo in some case, do not need to be updated to understand it. - Do not need to modify dillo internals or few Cons: - Dpid, dpidc and DPIs need to be modified - And more, sure Protocols and mime DPIs Based in the xproto DPI i think that a DPI can manage all the protocols and mime formats that dillo do not understand. Dillo simply passes the url or stream(or file location) to that DPI when it do not understand the format and the DPI using a list call the right DPI, script, wathever to manage it. That last DPI open an app, return a data in format that dillo understand(html, gif, jpg, png), etc. Image/objets html tags can call the protocol_and_mime_DPI, with some care and a especial dpi tag, so new formats can be viewed in dillo, if a DPI converts them to formats understanded by dillo, in the right place in the page. A interesting idea is to can embed apps, like sylpheed embed dillo, in the space of a image or object with new tags and/or pasing the WID. The protocol_and_mime_DPI send a html page to dillo when there is more than a DPI or action, download included, for a protocol or mime to ask the user what to do, set default action, etc Pros: - All code is outside dillo - Compatible with all Cons: - Can need news dpi tags - And more, sure HTML GUI When dillo support frames(The only think because i do use an old dillo 0.8.0 patched with frames sometimes is because it have frames)/iframe/objects(this tag can include html to, but frames are better) the dillo GUI can be a html page, with a iframe that contains the viewed web page, and a DPI that modifies the GUI html page. The new thing is that the DPI can use a cache file with that html page that dillo loads at start so dillo init is as fast as now, only loading the DPI when needed. All DPIs that generate html must use the same CSS so all have the same look. Pros: - Make dillo core small - Look is fully configurable - DPIs can register menus and buttons and dillo do not need even to know or have the list of buttons or menus registered in mem an in each dillo Cons: - Need to add remote control dpi tags to dillo - And more, sure Adding all Only frames, and new dpi tags need to be done in dillo core and it gives, when the DPIs needed and dpid are done, a very flexible interface to cordinate DPIs and for example that the DPIs GUI elements can be implemented step by step based on funcionality without touching dillo internals and not all at same modifing dillo core or doing it unestable. Only some ideas. If somebody wants to disscuss them, destroy them, blame about my english or me and my sleep state at this time i have my e-mailbox and eyes open to read all of them. Diego Sáenz/DarkSpirit.

June 25, 2005

Re: [Dillo-dev]dillo-0.8.5.tar.bz2

by Liam J. Foy

On Fri(17)/Jun/05 - , Jorge Arellano Cid wrote: > Hi there! > > Well, everything is ready for the official announcement of the > newest release of dillo (v. 0.8.5). I'll post in freshmeat > tomorrow in the morning. > > BTW, I included a GPG signature for this release, so please > remember to pick my new key (available from Authors page or from > a keyserver) if you want to verify it. > > > -- > Cheers > Jorge.- > Lovely work Jorge & Team! -- - Liam J. Foy liamfoy(a)sepulcrum.org

June 19, 2005

[Dillo-dev]dillo-0.8.5.tar.bz2

by Jorge Arellano Cid

Hi there! Well, everything is ready for the official announcement of the newest release of dillo (v. 0.8.5). I'll post in freshmeat tomorrow in the morning. BTW, I included a GPG signature for this release, so please remember to pick my new key (available from Authors page or from a keyserver) if you want to verify it. -- Cheers Jorge.-

June 18, 2005