Search results for "plugin" - Dillo-dev

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Tue, Jun 18, 2024 at 03:28:20PM +0200, a1ex(a)dismail.de wrote: >> This also allows patching the HTML of sites so you can fix them to >> work better (or at all) in Dillo. This is also done by Firefox from >> the webcompat[2] project in what they call "interventions", as >> sometimes page authors don't fix them or take a long time, so they >> patch it from the browser directly. You can open about:compat to see >> the long list of patches, here[3] is one for YouTube. > >This would be very impressive, a real step forward for Dillo in my >opinion. Do you think this is something that would be relatively >straight-forward to implement, or is it more of a long-term goal with >lots of work required to get there? Either way, sounds like there are >exciting times ahead for Dillo! Adding a mechanism to rewrite the HTML is surprisingly not super complicated, as the internal design of Dillo is centered around the CCC, the "Concomitant Control Chain", which is basically a chain of bi-directional pipes connected together to pass data around. Here is how Dillo currently receives data from the a TLS server (AFAIK). I'm only drawing the incoming direction, but the outgoing link is similar. Net +--------+ +-------+ +------+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |--->| CACHE |-... +--------+ +-------+ +------+ +-------+ src/tls.c src/IO.c src/http.c src/capi.c And adding a new rewrite module (named SED in the diagram) would require rerouting the chain to add a new element (not hard): Net +--------+ +-------+ +------+ +=====+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |---># SED #--->| CACHE |-... +--------+ +-------+ +------+ +=====+ +-------+ src/tls.c src/IO.c src/http.c | src/capi.c | +---------+ | rulesrc | | ... | +---------+ The module can then forward the content parsed from the HTTP module to the appropriate scripts defined in the rules, and then read the output and forward it to the next steps in the chain. When no rules apply, it can just forward the content to the cache as-is. Now, the interesting part is that we can place another SED module between the IO and the HTTP nodes, so we can rewrite the HTML content *and* the HTTP headers too. This would allow for example writing a plugin that matches a given mime type and on-the-fly rewrites it into an HTML file changing the Content-Type header. This is already done by the plugins, but they mix the two things together. For example we can display a .gmi file served via the "gemini:" protocol, but we cannot display a local .gmi file. Same for manual pages with the "man:" protocol, which cannot open manual pages served via "file:" or "http(s):". The solution with the new design would involve: 1) Open a "gemini:" link 2) The request is routed to the gemini: dpi handler (like now) 3) The gemini plugin returns the .gmi file as-is as an HTTP response, instead of converting it to HTML 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML in the SED node. Now, if we open a .gmi via HTTP: 1) Open a "https:" link 2) The request is routed to the usual HTTP/IO/TLS chain 3) The HTTP server returns the .gmi file as-is as an HTTP response. 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML in the SED node. Notice that the HTTP content can be compressed. So, for example, this simple rewrite script: #!/bin/sh sed 's_www.youtube.com_inv.vern.cc_g' Would only work well in the SED node *after* the HTTP content is uncompressed and the headers removed. The rewrite rules should indicate in which position of the chain they apply. As a side note, keep in mind that all of these pieces work in stream mode. Each node reads a bit of data, process it and sends it to the next node of the chain, without the need to store the whole thing in memory. Same with that sed command I wrote as an example. Best, Rodrigo.

4 months, 4 weeks

Re: [Dillo-dev]protocol handler dpi for mailto:, etc.

by Jorge Arellano Cid

On Sun, Oct 31, 2004 at 10:41:14AM -0330, Lee Bigelow wrote: > Hello again, Hi! > I did up a proto-type bash shell dpi for handling > unsupported protocols, like mailto:, with external > applications. I called it xproto. > > It uses the config file $HOME/dillo/protorc to > decide what to do. The plugin will make a default > one you can edit when it's first run. > > I'm working on the C version, but I'm just > learning C, so it'll take me a bit. Good you made a prototype. Dpi isn't that hard to program and I hope your code will encourage more developers to try it. > > One thing I can't seem to figure out is how to > send a url from the plugin to dillo and have dillo > display that page. For example I would like the > url gg:water to send dillo > http://www.google.com/search?q=water For now I > just have it open up another dillo. I tried > sending <dpi cmd="open_url" > url="http://www.google.com/search?q=water"> but > that didn't work, booo. Try the small patch below. It's a no frills version to keep you going on... Beware that there's a safety test in the function: Capi_verify_dpi_url_request() (Safety test: only allow dpi-urls from dpi-generated pages.) To avoid the "permission denied" message, while testing the patch, I asked for bookmarks (dpi generated page) and then the hello dpi (that was modified to send 'open_url'). If this is too much trouble, just disable the safety test! :-) > > Again, xproto.filter.dpi is just a shell script, > so play away. If you have any hints on the gg: > thing let me know, please... Please post the next prototype as an URL. If you don't have access to a web server please ask Jörgen to put it on our downloads directory. Sometime ago someone asked about how to make a slide show with dpi. Another thing to have in mind is how to tell a running Dillo to display another URL (for instance for sylpheed, or slides, or help manual apps.). Please try the small patch. That's the basis, details need to be thought better. ... & tell us how it works for you! -- Cheers Jorge.-

20 years

dillo-0.8.0-pre

by Jorge Arellano Cid

Hi there! It took a lot of time and effort, but finally the base for the next release (aka. 0.8.0-pre) is in the CVS now. It comes with lots of changes and some rough edges. Check the ChangeLog for a summary. This is not polished, nor your good ole' CVS snapshot, it is more intended for people interested in playing with the new dpi stuff. The dpid (dpi daemon) still requires a manual launch, and there're several things to improve (commented inside the code). As for the new dpis: FTP: It works OK, but is silent. This means it will not tell you what is doing until it's done. This is simple to fix and is a matter of capturing the stderr from wget and sending back some messages to dillo. You can download with the downloads plugin (right click on the link and "save as"). Downloads: It uses wget in a separate process (if dillo crashes, the download will survive). It can handle multiple downloads at the same time. It's also silent by now, but there's a guy that's working on a nice GUI that will provide all the necessary interfacing (aka Bells and Whistles). I'll ask him to share the code when it gets to a more advanced stage. Https: Unfortunately it doesn't work well (only for single, trivial, documents {with no image links} or single images). The problem is not within the plugin but with internal buffering inside dillo's core. I'll look at it when I have more time. There's an interesting discussion about suitability of UDS for HTTPS. Read the comments inside the code for more details. Hello: Just an example. This is the one you're supposed to play hard with if you want to develop a new dpi! Mailto: inexistent, but quite easy to develop. Just make the bindings and fork your favorite MUA. Cookies: Still need to be made a dpi (ported). That will solve our one-instance-only restriction. Read the docs! Ah, copy all the dpis to your ~/.dillo (we haven't defined where to place them yet). You'll also need a "dpidrc" in your ~/.dillo directory. Mine looks like: <q> /home/jcid/.dillo/bookmarks.dpi 0 /home/jcid/.dillo/downloads.dpi 0 /home/jcid/.dillo/ftp.dpi 1 /home/jcid/.dillo/https.dpi 1 /home/jcid/.dillo/hello.dpi 1 </q> Don't forget to launch dpid! That's all folks. Time to pause, recess, repose, break, rest ... Cheers Jorge.-

21 years, 3 months

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < > > obeythepenguin(a)gmail.com > > > > wrote: > > > > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < > > rf.opensource(a)gmail.com> > > > > wrote: > > > > > > > > Yes. Well, the only plugin I could see is the save button on the > > panel, > > > >> and > > > >> it can successfully navigate the filesystem and save a page correctly. > > > >> > > > > > > > > That one isn't a plugin, actually. Does the bookmarks button work? > > > > > > > > Yes, bookmarks work. (This is a bit of strange implementation of > > bookmarks, > > > no? took me a bit to find out difference of section and item) > > > > Good! > > > > If you can see the html page from the bookmarks, it means the > > whole dpi framework is working on Mac; they communicate using > > sockets. > > > > So it seems the main thing pending is socket support in fl_wait > > for Mac (see my previous email). > > > > Yes, I also think it's the source of this problem (see my other email). > > But what really perplexes me is that this happens only when I enter a URL > manually. When I follow links from one page to another it never happens. Are > you guys using different (FLTK) functions when opening a new page or > following a links (whether in the same tab or in a new tab)? No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo). > And it seems that as Dillo "warms up" I get less of this problem... Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-) BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac). -- Cheers Jorge.-

13 years, 5 months

web bug save?

by corvid＠lavabit.com

I wrote: > I wrote: > > I wrote: > > > Johannes wrote: > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > Sometimes I wonder whether > > > > > connecting through to a TOR network could help us a lot with it. > > > > > > > > You can already use dillo with privoxy and tor. We could perhaps > > > > make it more convenient to configure such a setup. > > > > We also would need to make sure that really all requests go through > > > > the proxy, e.g. I'm not sure, whether wget called from dowload.dpi > > > > uses the proxy from dillorc. > > > > > > I have warnings in the FAQ and dillorc that the wget env variables would > > > need to be set appropriately, but it would be nice to have dillo send that > > > to the dpi in requests so that it can set the environment for sure before > > > execing wget. > > > > I just committed a patch to set the environment variable from the preference > > if it wasn't already set. > > > > issues: > > - maybe we should have an ftp_proxy pref, too. > > - ISTR that dillo doesn't understand user/pass in URLs. > > This means that dillo doesn't do the right thing if > > - the env var has the user/pass > > - dillo is setting the env for wget. > > It turns out that if I want to add the ability for ftp/downloads > to do the right thing with the no_proxy pref as well, > I would have to send a no_proxy arg to the dpi. > > It would be cleaner to send the proxy URL to the dpi > (and set/clear it there in the environment for wget) every time > that it's needed than to have the proxy URL in the environment > and send a no_proxy arg when it's needed. > > So I'm going to back out that change. This turns out to be a somewhat complicated situation. I naively imagined that whatever I found in wget's 1500-line manpage was what there was, but since wget is a gnu program, it's a subset selected who-knows-how. wget understands the http_proxy, https_proxy, and ftp_proxy environment vars. dillo understands the http_proxy environment var. If it is not set, dillo will use the http_proxy pref. dillo uses its http_proxy value for both http and the https plugin. Whatever we might do to get *_proxy set a certain way in the environment in the downloads/ftp dpis, wgetrc can override them. - should the https plugin use the https_proxy environment var if it's set? I'm leaning toward no. - should dillo try to set the https_proxy env var from the http_proxy pref for the benefit of the downloads dpi? Well, the downloads dpi doesn't like https anyway right now because we haven't given it any sort of #ifdef ENABLE_SSL add argument "--no-check-certificate" #endif, but we could and probably should add the argument. As for the question, ... not sure. (Maybe we should just let wget do all of our https, at least instead of the current plugin.) - should dillo have https_proxy prefs and ftp_proxy prefs? On one hand it might minimize confusion, but then I could take the same amount of space in dillorc to write a big comment explaining all of this. (The unpleasant part of putting things in dillorc or explaining things in dillorc is that I know that no one who upgrades is going to look through it meticulously to see what tiny things have changed.) wget also understands the no_proxy environment variable and wgetrc option. Dillo understands the no_proxy preference. Coincidentally(?), they have the same format. - Should dillo set the env var for wget from the pref if not set? I think so, for the benefit of http downloads. - Should dillo use the env var for itself if set? I kind of don't want to add the complexity. I don't know. (And to get user/pass into wget for proxy, it seems that the proper thing is to stuff them into the env var *_proxy urls.) Anyway, I'm finding this all somewhat tricky to think about.

14 years, 10 months

Re: [Dillo-dev] How to get dillo up to speed; was: LinuxBIOS with X Server Inside

by Alan Carvalho de Assis

Hi, 2007/3/20, Justus Winter <4winter(a)informatik.uni-hamburg.de>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey folks :) > > I completely agree with Marc on this topic. I have been following this > list for some time now and I have heard all kinds of people proposing > interesting uses for dillo and I like to add one more to this list. > > I have done some research in web security, mostly session riding based > attacks. Dillo, with its missing javascript interpreter and css engine > being a feature this time, is not vulnerable against most session riding > attacks. > > Though most session riding attacks require javascript, it has been > shown, that port scanning and web server fingerprinting is possible > using only html and css. > > So why not use dillo on workstations in your internal network to protect > your intranet web applications against malicious javascript and css? > > Also with its small codebase (compared to geckos), some kind of auditing > might be possible. > > But on the other hand, more and more web sites and web applications > require css (which is definitively a good thing) and javascript (which > may not be a good thing). The web is a moving target, and everyone > developing a web browser is playing catch up with the standards and with > the ever growing demands of users and developers. > > And I for one think, that no one of the big four is doing very well... > > Dillo development has stagnated. So with every day that passes, dillos > practicability, the number of users and the number of developers > interested in doing some work for dillo decreases. > > I can understand Jorges bitterness, but this wont get dillo anywhere. If > its more work for a company (-> money and time) to get dillo up to speed > to meet their needs than to strip down gecko or khtml until it fits into > their devices (or whatever they want to do with it), they wont choose dillo. > > With every single day, the value of the dillo codebase decreases. And on > some day it wont matter if it is ever released or not, because it is > completely useless for the applications and sites out there. Maybe this > day has already passed without any one noticing. > > By the way, I keep referring to "the code". Yes I know that the GTK > branch is out there. Yes, I have taken a look at it and yes, I began to > develop an plugin, but I realized that the plugin interface was lacking > some important things (registering uri handlers comes to mind - it is > hardly an plugin if you need to touch and recompile parts of dillo). > > So I stopped before I began any serious work. Dillo felt dead. No one is > going to invest time in an project which was somewhat abandoned by its > main developer. No offense, but this is how it feels. > > Most free software developers are working on these kind of projects in > their leisure time, they want to have fun. If dillo wants to attract > developers, developing dillo needs to be fun. There are lots and lots of > free software projects that discussed how to make developing their > software fun. Things like giving write access to repositories to > developers interested in development, creating branches or creating a > wiki could help. > > It is somewhat true, that one or two developers working on dillo full > time would be nice, but as long as no one pays for this, I don't see how > this is possible. But this all or nothing attitude will kill dillo in > the long term. > > Jorge, consider releasing this patch of yours. You have got very little > to loose (or am I missing something?) but this might spark some interest > in dillo development again. > > Just my thoughts... > Sure, I agree with you! As can be seen at: http://www.dellideastorm.com LinuxBIOS is the 10 most voted idea to Dell implement. If you get Dillo running inside the LinuxBIOS the interest in this web-browser will increase newly, then now it the time to Dillo show its worth. Jorge, consider this. > > Cheers, > Justus Cheers, Alan

17 years, 7 months

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > > > [...] > > > Did you take special care to compile fltk-1.3 with X11 backend? > > > If not, you might run the dillo as native Cocoa application. > > > In that case you were more successful then me. > > > For me dillo with Cocoa-fltk starts, but does not load any remote > > > pages. There seem to be severe issues with the way fltk handles events > > > in the Cocoa case. > > > > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my > current > > native version is so close to working with no problems... > > Yes, it's amazing how close it is from working native. > Are plugins working OK? (e.g. can you browse the filesystem?) > Yes. Well, the only plugin I could see is the save button on the panel, and it can successfully navigate the filesystem and save a page correctly. > > Do you know how to use gdb? > It would be great to know in what functions the busy wait happens. > It could be a timeout or anything. For this: gdb ./dillo > <when locked on high CPU usage, hit Ctrl-c> bt > Yes, Here's the result. I tried it a couple of times, and this looks like the culprit: #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case: #0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431 -Reza > This can hint us on what may be happening. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

13 years, 5 months

Re: [Dillo-dev] Welcome & some news

by Sebastian Geerken

Hi, On Fri, Dec 27, Jorge Arellano Cid wrote: > The plan is to integrate a few more patches I still have in the > queue, before digging into dpi to make it work with unix domain > sockets, and to enable automatic plugin launching. After that, a > bit of testing and the next release will hopefully happen by late > January. Since the release has been delayed a bit, I've now already checked in the re-implementation of text search (originally planned for 0.7.1). Expect some more smaller changes in the next days. Sebastian

21 years, 10 months

ftp support?

by TheStar

Does FTP work? The page about achieved goals states that: "Fixed the plugin handler (FTP works again)" ? Any info about this?

21 years, 9 months

Re: https approaches?

by Ami Fischman

Thanks for the great summary. It looks to me like Jonathan Springer already implemented the BIO approach for 0.6.5. The fact that it isn't integrated in 0.7 discourages me from re-writing it for 0.7. Since implementing https as a pluging will require a change to the core dillo code (AFAIK only dpi:/ URL's get handed to plugins), it would be nice to get confirmation from the authors that this is OK (would be a candidate for merging in) before spending the time. Jorge? Cheers, -- Ami Fischman usenet(a)fischman.org

21 years, 8 months

Dillo-dev search results for query "plugin"