Search results for "plugin" - Dillo-dev

Re: [Dillo-dev]dillo-0.8.3-rc3

by Kelson Vibber

Jorge Arellano Cid wrote: > I found a bug that could increment the redirection counter when > the HTTP answer is a redirection coming in several tiny packets. Daniel Lord wrote: > What about setting MTU of your ethX to a small number? Hmm, that might be it. I'm not going through a proxy, but I am going through a broadband router connecting via PPPoE. I just tried it from work, and browsing from my desktop (through the firewall) shows the same problem (on the search form, anyway), but connecting from an outside system (directly over ethernet) seems okay. Jorge Arellano Cid wrote: > Even more, the search is giving me no redirection but a plain > 200 OK answer. Look: Agh. I've got a caching plugin on the journal that saves the HTML output to cut down on database & processing time. It looks like it's caching the search results and just sending them as 200 instead of processing the pre-output part of the script. This explains the apparent inconsistency in which only the first hit triggered the spurious loop error: later hits picked up the cached copy with a 200 instead of a 302. Sorry about that. I've disabled it for now -- the only reason I really had it on was to deal with delays talking to Waypath, but they seem to be down half the time anyway. (In the long term I can set up a separate page to handle searches, and just tell it not to cache that page, but for now, this is simpler.) That should help with the debugging, since I won't have time to put together a test case today. -- Kelson Vibber www.hyperborea.org

20 years

SSL in the browser

by johannes.hofmann＠gmx.de

On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: > Jorge wrote: > > Oh, as our mailsearch doesn't work anymore, is there > > and URL to the original thread (Gmane style) or something? > > > > I'd like to remember what the main point of having SSL inside > > the browser were. I'm getting old. ;) > > Looking briefly, I couldn't find relevant discussion. Possibly it > was off list. My recollection is that, at the time, it had to do with > seeing how SSL was becoming more and more central to browsing with > things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' > coming along and the issue of privacy gaining increasing public > awareness. > > As for this effort now, I started just by wondering what it would > look like if I integrated Benjamin's code and took out the windows > stuff. It was working pretty well very quickly. And now I like how > much more respectful of servers and resources Dillo can be when > HTTPS is integrated with the http_max_conns queuing and > http_persistent_conns. I think Johannes mentioned something about > Dillo and Tor not working together so well with HTTPS in a dpi, > but I don't know the details there. There is a potential loophole if you start dillo in a torified environment and dpid is running outside. Then https connections go via the non-torified https plugin. It's a small detail, but it happened to me. I'm mostly interested in getting SSL support from unmaintained experimental state to properly supported and maintained option. Cheers, Johannes

10 years

Re: [Dillo-dev]Re: HTTPS

by Garrett Kajmowicz

> Typical console error mesage (from yahoo mail secure logon page) > > lookes like: > |----------------- > > Nav_open_url: > Url=>https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50 >fau8u&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done=< url_str > = > https://login.yahoo.com/config/login?.branch=&.src=ym&.v=0&.u=bh9jje50fau8u >&.last=&promo=&.intl=us&.bypass=&.partner=&pkg=&stepid=&.done= main.c:153: > get_command: dpid tag is NULL > > : main.c:326: main: get_command failed > : {In https.filter.dpi} > > SSL_connect failed > Dpi: [Dpi_process_io] IOClose > > |----------------- > > and dillo provides no other feedback. Since I usually involk > dillo from my window manager, the console output is not normally > availible to me. I will take a look at it as soon as a I get a chance. > > Perhaps returning a SSL connection failed page would be nice. I'll see what I can do. I'm worried about code bloat, esp since Dillo prides itself on being very small. > > Dumb question: Is http 1.1 authentication amenable to a similar > treatment? That is one of the features I really miss. http 1.1 *anything* would require Dillo to support HTTP 1.1 When workingo n the HTTPS plugin, all of the requests that I pass through are HTTP 1.0 messages, meaning that we are indicating, at least to the other server, that we don't support any HTTP 1.1 features. Actually, all the HTTPS filter DPI does is open up an SSL connection to the remote computer and then pass all the HTTP connections through. THe only thing that makes it complicated at all is dealing with certificate isssues if they are invalid. - Garrett Kajmowicz

20 years, 4 months

Re: [Dillo-dev] Re: reason for Dillo's existence

by higuita

On Thu, 8 May 2003 17:12:31 +0200, Diego Sáenz <melchizedek(a)wanadoo.es> wrote: > I have a Pentium 150Mhz with 16Mb of RAM. Dillo is the only graphic > browser i can use well. This is enought to me. By the things i have read a 486@160Mhz (overclocked from 133 ) with 64Mb dillo startup in about 2 seconds i can have 20 windows open with no problem at all... with opera and konqueror i cant have more than 4 open windows because the computer/browsers gets too slow even without https, css, (normal) ftp, javascript, dillo is a great browser, most web pages works well and surfing the web is again a pleasure, fast, the only the stuff that matters and in the future, the plugins support will add all the missing things just remember, the text and some images are the core for the web pages, the animated gifs, flash, strange javacript, etc are good but most of the time, not really needed, in fact, some times they only get in the way 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

21 years, 6 months

Re: [Dillo-dev] Bug 433

by Jorge Arellano Cid

On Sat, 22 Mar 2003, Andreas Schweitzer wrote: > Just to clarify a bit the stuff that is now in the arcives ;-) > > On Fri, Mar 21, 2003 at 06:51:47PM -0800, Geek wrote: > > Thank you - the problem is solved. I completely removed using "make uninstall" > > then using my trusty Midnight Commander, hunted down all the remnants and > > directories and removed them. I re-downloaded Dillo, installed from scratch and > > it seems fine now. > > > > I had tried reinstalling one already to no avail, but I had not removed /.dillo > > before, in order to keep my bookmarks, cookies and rc file. > > Now careful ! I meant to remove ONLY a possible > bm_srv12 sitting in there. One more thing. If the server is running: ps aux|grep bm_srv kill <bm_srv's PID> Cheers Jorge.- > > > So I guess the lesson here is - when upgrading Dillo, wipe *everything* old > > Dillo out completely, first. > > No, not wipe everything. Just make sure, that any new > executable gets installed in the BEGINNING of $PATH. > (this is really not that surprising :-) ...) > And that you don't have any old executables in ~/.dillo/ > > dillo searches (at least the bookmarkserver for now) first > in ~/.dillo/ and then in $PATH. This can be handy for > developing plugins but can be confusing, too. > > Cheers, > Andreas > > -- > **************************** NEW ADDRESS ****************************** > Hamburger Sternwarte Universitaet Hamburg > Gojenbergsweg 112 Tel. ++49 40 42891 4016 > D-21029 Hamburg, Germany Fax. ++49 40 42891 4198 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

21 years, 7 months

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

by Oliver Haertel

Slackpacks here: http://www.linuxpackages.net/details.php?name=dillo On Tue, 5 Aug 2003 13:58:31 -0400 (CLT) Jorge Arellano Cid wrote: > > Hi there! > > Yesterday I posted an email about 0.7.3 but forgot to mention > the most important part: the URL! :-) > > There's a tarball of 0.7.3 at: > > http://www.dillo.org/download/dillo-0.7.3.tar.bz2 > > > The plan was to test it yesterday (it already passed my tests > and Seb's too) and to announce it on Wednesday while letting our > packagers some time to update them for announce time. > > So there it is, and will be announced on Thursday. > > Please get it and give it some hard testing. > > Kelson, Phil, Oliver: please make update your packages with it. > > Sorry for the mistake. > > Cheers > Jorge.- > > Frank: after I upload 0.8.0-pre I'll have some time to look in > your work. Now that 0.7.3 release is almost done, I guess > Sebastian will have some time too (we were working on a plan for > CSS, and then Sebastian had to make a detailed review of the > incremental resizing mechanism because of some discovered bugs. I > was working on 0.8.0-pre (plugins) and on the release). All this > explanation is to state that it is not lack of interest, but lack > of manpower. You'd be amazed to know all of the things I'm > working in parallel. > > PS: the above note applies to all of you waiting for an answer > from my side... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

21 years, 3 months

Re: Towards 3.2.0

by Kevin Koster

Rodrigo Arias wrote: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" One action which would probably complicate things, but likely be among the most used for me, would actually be something like "View as text" (in Dillo). Effectively the inverse of "Save link as...". Websites with annoying MIME settings can give links that one wants to view as text (eg. source code files), but the server assigns a MIME value to them that makes Dillo download them to file. This would force Dillo to display the link as a Text file regardless. Also the view source plugin/rendering can choke a bit performance-wise (on the modestly-powered computers I use, at least) with the multi-MB webpages that are common today. Just viewing as text might be a quicker option, eg. when looking to manually extract a URL meant to load via Javascript. This would be a separate feature to implement, but maybe it would be a good fit for the same sub-menu. > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. What would the default behaviour be? Will Dillo install a default handler with its own separate configuration file for setting up the default 'action' behaviours? Or does the feature only appear after each user has created their own handler?

3 weeks, 1 day

Future of dillo2

by sgeerken＠dillo.org

Hi, just if you were courious: I'm still living and will continue working on dillo. On Sun, Apr 20, Jorge Arellano Cid wrote: > [...] > We could: > > * Attract new developers with a dillo2 release, > leveraging the excellent documentation that we have. We have: - extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins. These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.) For those not listening to dillo-dev, it is important to know that dillo is still an active project. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS. > * Coordinate with FLTK2, DSL (Damn small linux) and other > lightweight distros, Debian installer team, MINIX3, etc. Perhaps we can find there other "lightweight zealots". :-) Sebastian P.S. I'll soon review the changes regarding redrawing and related. When working on floats, I noticed that the redraw optimization after resizes does not work fully correctly, there are situations where only a explicit redraw (e.g. hide and show window) makes size changes visible. P.P.S. In the doxygen documentation, there are two lists, html/bug.html and html/todo.html (generated from the \bug and \todo tags), with open issues. Furthermore, some problems are described in html/fltk-problems.html.

16 years, 6 months

Re: Fwd: Re: [Dillo-dev]Plugin infrastructure

by Jorge Arellano Cid

On Mon, 12 Jul 2004, Garrett Kajmowicz wrote: >> In the discussions before introduction of dpi was the point UI could >> entierely be done using standart html, rendered by dillo itself. >> >> Maybe we could use this here. >> >> I would see two (new) dpi commands: >> -Pop a new dillo window (maybe with some args: modal, no toolbar, no >> addressbar..., set its size, url) >> -Make a window reload >> >> So dpi could make a window pop for asking anything about certificates, >> with a standart html form in it. It would allow to change window title >> (through <title>) and make the gui customisable for future needs, and >> even be portable for gtk->other toolkit change. >> >> I thought of the 'reload window' feature not directly for https, but for >> download dpi. This would allow us to update the status of current >> downloads; shown in a dedicated window, somewhat ala Firefox, but again, >> entierely in html. Yes Nicolas, the html interface is an important part of the dpip feature set. Now, each dpi is different and that's why flexibility is important. I mean, for bookmarks and preferences (and probably for general purpose applications like the dillo-based control center of DSL linux), HTML is perfect. For the downloads, a native GUI inside the dpi, is an easier approach, and in the https case, dialog windows through Dillo by means of a dpip request seem to be the most adequate. > > That is very interesting, but causes two problems. First of all, from what I > have seen , it looks like it would be difficult to implement modal dialog > boxes. This is important for security warnings so that they are not hidden > or confused with other Dillo warnings. > > Secondly, this approach causes some problems. I am approaching this from the > perspective of the https filter dpi, but I assume that the same problem would > apply to any other related dpi. > > Firstly, a filter dpi runs in its own process for each call, not as a server. > Thus every time a call is made to the https filter dpi, it runs in its > entirety. This makes it difficult to handle a response from the user because > the dpi is then required to write a web server capable of at the very least > parsing http GET requests, which means opening up a socket and so forth. > Needless to say, handling that is somewhat of a challenge from a filter dpi > perspective. > > Secondly, for the https application, cookie/post/get datais likely to be > sent, which means that any rerequest would have to be able to pass that data > on exactly. > > Third, the https verification needs to be done after the ssl session is > estabilshed, but before the http request is made (for security reasons). > Thus any complicated scheme could result in multiple connections being made. > > Fourthly, I don't like it. That's the most important one of all :-) It's important to notice that coding the https dpi as a server (instead of a filter) has some advantages. BTW, this is what we have in mind with Madis. A server https dpi can more easily manage session caching and certificate management (remembering, saving, loading, ...). A single instance that forks or launches threads to do the work while keeping a common central management. BTW, we agree that implementing and testing with a filter dpi before turning it into a server dpi is a good approach. > > The html prompt window isn't a bad idea, but causes a lot of coding headaches > on the dpi other end. But that's just my thought. If you think that an > html prompt window would work, I'd appreciate a modified "hello" filter dpi > as an example from which I could implement the required code. In this case we'll try the dialog window with dpip... I foresee this tasks (by my side): 1.- Merge the https into the CVS so you can sync from there. 2.- implement a dpip command to provide for a simple dialog. (so handle_certificate_problem() can be filled in). 3.- Polish the common API for developing dpis and adjust the dpi set to the new functions. 4.- Implement a dpip_build_command() function into the lib and make the dpi set use it. 5.- Merge my new patches for bookmarks, downloads, and interface inside dillo. 6.- Review the file dpi. I hope to have this done and uploaded by Friday (1 to 5). Now, only 1.- and 2.- constitute a bottle neck for https, so I'll try to push them first (hopefully by Wednesday). The idea is to remove the bottleneck so you can keep on working and testing the https dpi. Cheers Jorge.-

20 years, 4 months

--xid option

by Johannes.Hofmann＠gmx.de

On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > used to embed dillo into the claws mailer. > > > > The right way to do this would probabely be to implement the > > > > complete XEMBED protocol which is also mentioned in > > > > doc/fltk-problems.doc. > > > > However a simple XReparentWindow() seems to work more or less here. > > > > Please test. > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > e.g. hg add xembed.hh xembed.cc > > > > Oh yes. Should be fixed now. > > Btw. I managed to install the claws mail client including the dillo > > plugin and it seems to work fine now with dillo2. That's why I just > > committed the xembed stuff. > > This is very good. > > I'll have to dig for the sylpheed contact to let them know. > Does anybody here know the email? I already contacted them on irc (#claws on freenode). It would be good if this get's some testing as there seems to be some interaction with the WM in use. I now tested it successful on dwm, twm, and fvwm. Also there are probabely more elegant ways to do it, but for now I think it's better than nothing. Cheers, Johannes

15 years, 5 months

Dillo-dev search results for query "plugin"