Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] Re: https approaches?

by Madis Janson

On Mon, 17 Mar 2003, Jorge Arellano Cid wrote: > As SSL has a high priority on my list, it would be a matter of > writing an external program that does https (given the URL), > retrieves the resource, performs any other required tasks and > reports it results somewhere. > > That is, I'd make all the necessary bindings/extensions in > dillo's core to accomodate the plugin. > > AFAIU, the most basic communications required between dillo and > the https dpi are: > > 1) -> Send the https URL to retrieve > 2) <- Maybe make the user confirm the certificate acceptance > 3 <- https resource > Does this mean that https plugin should implement http protocol by itself? It wouldn't be too hard using for example the curl library, but a downside is that most dillo http features (like cookies support) would be omitted.

21 years, 7 months

Re: [Dillo-dev]Preparing the 0.8.1 release

by Daniel Fairhead

Hi, > That is, the new parser (going to lots of sites and asserting > there're no crashes), and the recently found problems with puppy > linux and downloading and FTP (has anyone experienced trouble > with these dillo plugins on their systems?). New renderer seems good. Improvements on some sites. No crashes or anything like that. The FTP plugin seems to be working too, for directories. It doesn't seem to handle files though, it gives me "Illegal Seek" errors. A simple example is ftp.sf.net, and then clicking on index-sf.html or robots.txt. One question... if I go to an invalid ftp URL, it doesn't say in the statusbar "not a directory" or whatever, it only says so in the console, is this correct behaviour? Thanks all, Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

20 years, 6 months

Re: [Dillo-dev]Extension/plugin question...

by Daniel Fairhead

> Why isn't the magic button there then? > > Our main problem is lack of developers, Sebastian and I are > covered with other works we regard as higher priority, so handy > task as this (and several others) keep on waiting... > > If somebody here wants to implement this menu button in a clean > way (not as an ad-hoc hack), it'd be very welcomed. > > In the same spirit, if someone here has development skills and > wants to contribute, please let us know. We have plenty of small > to big size tasks waiting for a developer to work them out. I'd be willing to have a try at it. I'm particually good at it, but I'll try. Any hints or anything would be cool :-) Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

20 years, 1 month

Proposal: United Dillo

by Indan Zupancic

Hello, With "united Dillo" I mean that there is always just one Dillo running per user, so when you start Dillo while it is already running, then the current one will open a new window. I made a patch as proof of concept, see: http://www.xs4all.nl/~dorinek/dillo This approach has two big advantages: 1) Always one Dillo has less overhead than running multiple instances at the same time. 2) Automatic synchronization/no need for synchronization anymore. First advantage is in the spirit of Dillo, wanting to be small, light and fast. Second advantage means that doing certain things will be much simpler, like having always cookies, no need to synchronize plugins, meaning that dpid is not really needed anymore, because most of the points from the problem list are solved (see Dpid.txt). Problems that aren't solved: * Forks can be expensive (Dillo had to fork its dpis). But dpid does much more than simply forking: it forks and then starts up an external program (which often also forks and starts up wget). Beside, if Dillo uses library plugins then there is no need to fork at all. * It increments dillo's core size. The patch adds about 70 lines of code to dillo.c and increases dillo with about 1 K. It is true that if you get rid of dpid then more code is needed in Dillo's core. But that's only moving the code to some other place, no real increase if you ask me. Having a seperate dpid has much more overhead at runtime (seperate process versus bigger executable). You can always make a plugin handling library, then it isn't part of Dillo's core. Of course a united Dillo has problems/disadvantages too: It is sometimes still needed to synchronize multiple windows. If it's not implemented carefully, you may lose functionality (aka command line options). A user can't run more than one Dillo instance. Sometimes it's wanted to run multiple Dillo's, for instance two different versions. But that isn't possible at all, or if version awareness is added, without losing synchronization. What do you think about it? Greetings, Indan

20 years, 11 months

Re: a vulnerability in dillo

by Jorge Arellano Cid

On Sun, 2 Mar 2003, Ivan Popov wrote: > Hello, > > having read the statement about dillo being a secure browser, It tries to be! > I want to draw your attention to the exploitable in different ways > bookmarks plugin interface. > > I submitted it as a bug and mentioned denial-of-service only, but creating > predictably named sockets in /tmp opens to other possible attacks > (e.g. spoofing your bookmarks) as well. > > I realize dillo and the plugins are evolving at fast rate, but this issue > can (and should?) be fixed even on the early stages of development. Probably (soon) socket file descriptors will reside in /tmp/dillo and use temporary filenames, or something akin (this also solves the problem of a pre-existent file with the same name). > Thanks for the great software! > I appreciate dillo - it is small, fast and functional. Thanks for your nice comments too. Cheers Jorge.-

21 years, 8 months

XMPP PubSub Plugin

by Schimon Jehudah

Good day, to one and all! My name is Schimon, I am a pianist, attorney at law, and I also work on software that mainly involve the technologies of Syndication and XMPP. My current intention, is to design an XMPP client, based on Slixmpp, to allow Dillo to interact with Atom Over XMPP (XEP-0277 and XEP-0472). Atom Over XMPP specifies storage of textual content (be it text or HTML) on XMPP PubSub nodes. It is useful for publishing (see Libervia, Movim, Rivista XJP), annotating resources (see Blasta) and for any sort of mean which may require textual content. References: https://blasta.woodpeckersnest.eu/help/about/xmpp/atomsub https://blasta.woodpeckersnest.eu/help/about/xmpp/pubsub Projects: https://schapps.woodpeckersnest.eu/blasta/ https://schapps.woodpeckersnest.eu/rivista/ I intend to utilize the Python computer language for this task. Any help, encouragement, and especially accompanying (not in the musical sense) my efforts be welcome. This is my first time which I intend to collaborate with Dillo developers, and I am excited by this opportunity. Kind regards, Schimon

1 week, 2 days

Patch for xembed updated

by higuita7＠yahoo.co.uk

Hi > I don't know if the claws plugin is still used by anyone, but I > don't want to remove the code, that proved to be working. I use both dillo and claws-mail, where i load the dillo plugin... so, yes, it is still used, at least by me :) Thanks for dillo :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

11 years, 10 months

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

by Jorge Arellano Cid

Hi, On Wed, Sep 06, 2006 at 08:12:42PM -0500, R.L. Horn wrote: > I'm currently in the process of modifying dillo for use in browsing an http > media server (yeah, I know it's httpd abuse, but it's only for a local > network and I was running Apache anyhow). At present, this basically > involves sending a modified downloads plugin an "execute" command and the > MIME type when AbortEntry is true in Cache_process_queue() (the plugin then > executes an agent which deals with the URL entirely independent of dillo). > > (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. > > So far, so good -- it seems to work passably well and it only took a couple > of hours. Easy peasey. Unfortunately, the first time I click on a 700M > video stream, things go horribly wrong. > > Seems that Cache_parse_header() attempts to allocate memory for the entire > content *before* the header has been checked for viewability (since the > dispatcher isn't called until Cache_process_queue()). As it happens, this > has been reported as bug 726. Yes. I fixed this sometime ago in the FLTK2 branch... > > The upshot of all this is that when you click on a link, there had better > be room for the whole thing in heap even though the content may never be > read. Otherwise, glib just gives up and dumps core via g_malloc(). > > I think I can get around this by doing a Content-Type check in > Cache_parse_header(). I'd be happy to provide a patch provided I can come > up with a reasonably elegant solution. > > Any advice would be appreciated. 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. (My FLTK2 source uses automatic buffers from a new library I made that also replaces glib). -- Cheers Jorge.-

18 years, 2 months

Re: [Dillo-dev]Plugin infrastructure

by Garrett Kajmowicz

> In the https case, it seems we only need (by now) a yes/no > answer for a certificate that can't be verified. > > Please send me the list for all the question/generic dialogs > you foresee. > If we are going to allow dialogs we need to have something generic enough that developers will not feel straightjacketed, which concrete enough that it isn't a nightmare to implement. Ideally it will not be tied to the underlying widget library so that we can switch widget libraries(if need be) without having to rewrite plugins in the future. There are a few dialog types that I see as being useful. The first is the file save-as dialog. This might simplify some of the FTP code (I haven't looked at the core app side of things). Next, a generic dialog which supports a custom message, as well as customizable text on up to three buttons. Custom caption for the window is nice. I think we can assume that it's a modal dialog box. This will allow the programmer to deal with almost any situation needed. In the https example, consider the options of: trusting indefinitely, trusting for this connection only, or refusing the connection. That requires three buttons. The indefinite trust is required to deal with self-signed sites that we don't want to have to click "yes" to for every file. These are the two which come to mind immediately. I would avoid limiting the possabilities so that when we come up with something we had not anticipated we will not run into any problems. > The question dialog through dpip for continuing or aborting > over non-verifiable certificates, is the bottle-neck now. I'll > start coding it ASAP. Thanks. Please let me know what you are doing so that I can follow everything. This will make it easier for me to contribute. You noted that you had made some changes to what I sent you. Have you commited the changed to CVS? If so, I'll blow away my current tarball tree and pull everything down from CVS. If not, please let me know where you are going so I can adjust my development accordingly. Thanks. - Garrett Kajmowicz

20 years, 4 months

https plugin status

by jcid＠dillo.org

Hi, Just a follow up on https dpi: > [place wrote] > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead > of "https"... Yes this is a bug from the latest big dpi upgrade (generic dpi protos). > [Jeremey wrote] > Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* > adding the "proto." prefix? "proto.https" is the right patch. > [Christian wrote] > But what is supposed to be working atm? Really basic, if you can see: https://www.rapidssl.com/test/rapidssl.htm that's all. BTW, with place's patch, I can also see: https://www.ccc.de > [Jeremey wrote] > Getting https working would greatly reduce the number of times I run > Firefox! I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-) > [...] With regard to the missing dialog function, you may get a very good idea by looking at its implementation in dillo-0.8.6. That's what I'd do to answer if I had the time now. -- Cheers Jorge.-

16 years, 8 months

Dillo-dev search results for query "plugin"