Search results for "plugin" - Dillo-dev

Re: [Dillo-dev]https

by Brian Hechinger

On Sat, Sep 11, 2004 at 02:09:13PM -0400, Garrett Kajmowicz wrote: > > I sent in a patch a month or so ago, but I don't know if there is much more to > be done at this stage. Things seem to work well, and most error conditions > notify the user specifically. Those that don't give a generic error message > (very unlikely cases). > > I'm not sure where to go from here. The dpi infrastructure makes it hard to > do some things, but I guess it might be possible to convert the plugin to a > process. Other than that, I don't know if there is much more that needs to > be done. i've just started to get into this myself, and i've come to the point where i've realized that i'm not every going to send any money to any "proper" CA, so i've generated a CA Root Cert of my own. how so i import this into the dillo cert chain? i've not looked at this at all and should probably get the latest dillo before saying anything else [0] at this point. :) -brian [0] or anything at all for that matter? ;) -- "The cats tend to administer themselves, and contrary to the expected facts, the house and everything in it was installed for their benefit." -- Nic Clews

20 years, 2 months

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > > Johannes wrote: > > > > I noticed that since the recent DPI update pages which use > > > > cookies load slower (e.g. fltk.org) > > > > Do others also see that? It could also be OS specific. > > > > > > I thought it seemed weirdly slow _sometimes_. > > > I'll have to throw some gprof at it and hope for something > > > simple and embarrassing. > > > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > > plugins.) > > > > I did some truss on the cookies dpi and found that it is reading > > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. > > It looks like it checks it through a_Dpip_check_auth() when it > gets or sets a msg. As for whether it needs to, I don't know. > > I tried a little gprof, but a modest amount of browsing and > accepting cookies wasn't enough for the dpi to use up enough > time for gprof to generate stats. Yah, I don't think it's CPU bound. There must be something else. I will have a look at it.

14 years, 10 months

Re: [Dillo-dev] Some thoughts

by Lars Segerlund

I agree, I have been trying to 'break out' the bookmark dpi into a loadable object file, ( loads at runtime, and installs the button and such ), in order to do work on a dpi plugin myself. If something about loading dpi modules were in place it would be much nicer. I have tried to hack a list of dpi modules in .dillo/dpis which is loaded at runtime, but so far not much sucess. Is there a plan on how these things will work in the future ? Because then one can progress with the dpi itself and the infrastructure. / Lars Segerlund. Andreas Schweitzer wrote: > Hi, > > Just a comment on one of your plans : > > >> Appart from that, I still have to finish the design of dpi >>initialization, addition, managing etc. (needed to support >>several dpis at the same time). > > > I think this will be important, since it kept me somewhat from > playing with dpi's. I did some experiments, but an automatic > dpi initilization makes coding much easier. And I have the feeling > others think the same :-) > > Something like > dpi:/foo/ > starts the dpi foo[possible-extra-name-part] from some location like > $PATH or some other "repository". And > dpi:/foo/command > passes "command" to the dpi foo. > Just some rambling :-) > > Cheers, > Andreas >

21 years, 6 months

Re: dns over tls or dns over https

by Rodrigo Arias

Hi, On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: >Hi > >could someone give me an idea about dillo using 'dns over tls' or 'dns >over https'? or using dnssec? The mobilized fork has added support for it, as it is provided by libcurl (which they have switched to): > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > the preference dns_over_https_url. https://www.toomanyatoms.com/software/mobilized_dillo.html My recommendation is to setup a local resolver on your machine, so all name resolution is handled by it, not just Dillo. Then you can use whatever mechanism you want (DoH, DoT, DNSSEC...). This would be especially useful if you download a file with Dillo, as it would launch an external wget process. Or if you use any plugin that performs network operations on its own. Here are some docs (even if you don't use Arch): https://wiki.archlinux.org/title/DNS-over-HTTPS https://wiki.archlinux.org/title/DNSSEC I didn't check on my own how well that works, but I would rather keep it out of Dillo if posible. >what about dillo using mbed-tls vs openssl? >the configuration only shows a --disable-mbedtls The DNS resolution is done prior to interacting with any TLS library. There is also a --disable-openssl switch to search for mbed TLS only, see ./configure --help. Best, Rodrigo.

5 months, 2 weeks

Re: [Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter

by David McKee

On Wed, 11 Aug 2004, Jorge Arellano Cid wrote: > I've been silent for some time, working on a medium sized patch > that was just commited. Seems to work...the tables mode looks pretty good. I note that if I look at dir/, follow the link to dir/subdir/, switch the rendering mode, and hit back I get dir/ in the original rendering mode, but if I look at dir/, follow the link to dir/subdir/, switch rendering modes, and follw the link to dir/subdir/../ I get the new mode. So, the back button in looking at the cached file, not calling the plugin again. Not a big deal. A refresh always gets the most recently established mode. [In the table bsed file: rendering mode:] > Note that the stripes' slight contrast on the table-based mode > is meant for easy reading of the file names when looking for a > file by its filename. The contrast helps the eye (almost at the > unconcious level) to locate the right row of it, when locating > its type, size or date. Apple uses a similar thing in sufficiently new Finders. They use slightly more contrast, and I find that it helps more. It is, however, more visually intrusive. Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

20 years, 3 months

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by Jorge Arellano Cid

On Thu, Sep 07, 2006 at 07:38:27PM -0500, R.L. Horn wrote: > On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: > > >>(Actually, this is functionality that would be nice in the main branch, > >>albeit with its own plugin and user-selectivity. If there's interest, > >>please let me know.) > > > > Yes, more or less this is the plan. > > Great! > > > OK, a good workaround is to check for huge filesizes while parsing the > >header and to set as if no Content-length was given in that case. This > >is simple and will work. > > That's kind of what I did. Actually, I just removed the code that had to do > with static buffers entirely (while still allowing for a Content-length > check). > > If the GTK branch weren't pretty well deprecated, I'd go ahead and do it > right: Add a boolean to the "entry" structure to indicate a fully allocated > buffer and complete the allocation (where reasonable) at dispatch time. The flag is already there: > if ( (Length = Cache_parse_field(header, "Content-Length")) != NULL ) { > entry->Flags |= CA_GotLength; /*** Here! ***/ > entry->TotalSize = strtol(Length, NULL, 10); > g_free(Length); > if (entry->TotalSize < entry->ValidSize) > entry->TotalSize = 0; > } -- Cheers Jorge.-

18 years, 2 months

Re: [Dillo-dev]XML browser

by Sebastian Geerken

Hi, first of all, some time ago I planned to extract Dw from dillo, making an own library of it. I've polished it a bit so far, it can be downloaded at <http://www.dillo.org/misc_files/dw-core-0.1.0.tar.gz>. It is nothing "official" yet, but you should be able to play around with it. Notice that this only contains the core of Dw, not the specific widgets. However, it should be possible to copy them, but they need some (trivial) changes, to remove some dependencies from the rest of dillo. Furthermore, I already wrote some widgets, which are neither part of dillo (some kind of tree, a simple text box, and a widget, which may be used to toggle the visibility of another widget), these may be a start if you need something similar. On Tue, Mar 08, dillo-dev(a)moshe.nl wrote: > For some time now i'm looking for an XML browser, witch is simply able to > show XML documents. XML capable browsers that exist today do not suit my > (and others who extencively use XML) needs. Their XML implementation is > based on top of their html implementation, witch makes it incapable of > many standard XML features and also makes them bloated. > During my search I began to cave into the dillo source, and found the > dillo widget system. Witch seems to be a good rendering system for digital > documents, not just html. > > XML parsers already exist (libxml for example), and parsing XML is a lot > easier than parsing html, because it has a much more strict syntax. An XML > browser, maybe more acuratly named an XML viewer, is just as abstract as > XML itself. It has no way to know how a partucular XML document has to be > show'ed. For this purpose XSLT exists, it is able to "translate" any XML > document into another. > Thus creating a XML viewer is limited to being able to render one > particular type of XML document, and having XSLT documents available to > translate the rest. > > Luckily something like glade exists. Glade is an GUI development kit, > using XML to describe the GUI's, and GTX+ to show them. Dillo widgets are > an extention to GTK+, meanig glade can show them. > > Leaving the "problem" to creating the XSLT stylesheets te translate > documents to glade-XML. I'm in no way familiar with glade-XML, but there is at least one problem with this approach: dillo widgets are *not* Gtk+ widgets, instead, from Gtk's point of view, there is only one large widget (GtkDwViewport), Gtk+ itself does not care about the complex dillo widget tree behind. OTOH, coding the rendering yourself should be pretty simple. > The dillo widget is currently inside the dillo source, and only linked > directly to dillo. how posible is it to seperate this, and have dillo > widget inside a .so for example? See above. > As such an XML browser is not really aimed at the same goals als the dillo > project (as far as i've read, correct me if i'm wrong), i'd apriciate the > dillo widget into a seperate library. this way dillo and this XML browser > both can use the same dillo widget system, without forcing me to include > dw vith the XML browser. (and sync them constantly) There are no plans to make dillo use a Dw library, since Dw is changing frequently, so it would be necessary to have a new version of Dw for each release of dillo. However, there is a script within the dw-core tarball, which makes syncing very simple, see README. > I'm still only planning, so i'd like any comments on this idea, as well as > tips and other ideas. maybe you also have comments on the level of > integration dillo and the XML browser can have. Perhaps there may be a (graphical) plugin, which reuses Dw for the rendering (so that your viewer may be ported). I wrote something about this some time ago (it is part of the documentation about the "rendering abstraction"). Anyway, graphical plugins are not to be expected in the near future, there are currently other priorities. Sebastian

19 years, 8 months

[Dillo-dev]https

by Jorge Arellano Cid

Hi, Here's the https-relevant part of a private email: ---------- Forwarded message ---------- Date: Wed, 7 Jul 2004 10:25:24 -0400 (CLT) From: Jorge Arellano Cid <jcid(a)dillo.org> To: Brett Wynkoop <wynkoop(a)wynn.com> Subject: Re: dillo 0.8.2rc2 On Wed, 7 Jul 2004, Brett Wynkoop wrote: > [...] > I was surprised that there is no SSL support. I remember a recent > release used wget for ssl. Is there any way to re-enable that on the > current release? The problem is that our former plugin didn't do certificate authentication (among other things commented in the code). As the Dillo project takes security seriously, it was withdrawn from the newer releases... In other words, the https dpi allowed the user to see https URLs, but there was no security backing it. I know that some big browsers had the same bug for years, before it was made public. This allowed for instance, man-in-the-middle attacks by faking the destination site. Https is a very complex matter, and I'd rather prefer not to assert ours will be flawless. The least we can do is not to release one we know is broken. I hope we can make a good https dpi soon. If you want to use it anyway, assuming the risks, just get the https.c from 0.8.0 and drop it into the new tree. You will not even be able to post or send forms, but it'll allow to read some https forums. Atentamente Jorge.-

20 years, 4 months

Very close to a new release!

by Jorge Arellano Cid

Hi there! It's been a hard time for me trying to get an Internet connection from where I'm temporary living now. That's the main reason for my abscence (as anticipated). Well, I kept working on the plugins stuff and it shows. Now the CVS has the new code (with unix domain sockets) and the CVS.html page holds the new bookmarks-server tarball. Now dillo launches it automatically and before the release the dpi code for the bookmarks server will be a part of the main tarball. The point is: testing it. Sadly I didn't received more than a single comment of its working. Now I'm asking again: please download the latest CVS, the bookmarks server, intall them, play with them, test and report how it works for you. I want to know how the whole thing looks and feels before making the release. This should be a short span, depending on feedback. Ah, if someone here has NFS mounted accounts (from another machine), I want to know how it works there. As unix domain sockets are accessible only to the local machine, and it listens on /tmp, it should work, but we need the proof! That's all by now guys. I'll be expecting your feedback! Cheers* Jorge.- PS: I'll try to answer some pending issues, but roughly, this CVS plus some cosmetic will be 0.7.0. Pending patches will go to 0.7.1.

21 years, 9 months

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Thu, 25 Apr 2024 21:36:04 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > We can improve the content detection to handle both HTML and > XML-style comments, but I prefer to defer it after the 3.1.0 release. > Websites shouldn't rely on the browser to guess the content type, it > should be stated in the HTTP header or the meta tag. So I don't > consider this a priority that should block the release for longer. Yes, that's reasonable. > If you want to work on it, feel free to do so :-) I might have a go at it then. > >I've built Dillo from that branch and pages on www.lemis.com now > >render correctly, thanks! If I save the homepage as lemis.xhtml it > >still shows as plain text when loaded with file://, though it is > >rendered if the comments before <!DOCTYPE> are removed or if the > >original file is saved as lemis.html. Not much of an issue, but it > >could cause confusion for someone. > > I pushed another patch that should fix this issue. It is caused > primarily by the ".xhtml" extension not being recognized by the file > plugin, which then tries to detect the doctype and fails in the same > way, falling back to text/plain. All working well now, thanks again.

6 months, 2 weeks

Dillo-dev search results for query "plugin"