[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again
On Sat, Mar 15, 2008 at 09:45:40AM +0100, Christian Kellermann wrote:
I am not sure whether I should stop beating this dead horse or continue. What's your advice?
I would really like to see this working. What's the next step? Regards, Jeremy Henty
Skipped content of type multipart/mixed
Hi Christian, Sorry for the late answer, but I've had little spare time, and several topics to answer. Probably you have already read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.htm... an got some info from there. On Sat, Mar 15, 2008 at 02:02:07PM +0100, Christian Kellermann wrote:
* Christian Kellermann <Christian.Kellermann@nefkom.net> [080315 09:49]:
Dear list,
In order to fix the https plugin I have stumbled upon the fact, that the former dialog code seems to be removed from cvs. To see what's goign on further down the code I have added a basic Yes/No popup using the existing a_Dialog_choice3 function. For this the numbering of the buttons have changed also in https. Dialogs with more than two alternatives will have the additional choices dropped silently. This is good for now but I really like to have it done right. Which function should get used instead of a_Dialog_choice3?
Also what's the real purpose of http_request? At the moment I cheat and set it to url in case it is empty. Which value is to be expected when calling the document root in a URL? "/"? "/index.html"? or am I getting this all wrong?
Whith this patch I can bypass the "certificate could not get verified" case but not much further. Also cancelling the dialog seems to leave some data behind, another call of https URLs won't do anything. But this is a bit better than it has been before...
I am not sure whether I should stop beating this dead horse or continue. What's your advice?
Ignore the http_request part I figured it out.
Ok, I have changed the proto comparison from "https" -> "proto.https" and I am able to view https sites again. This module still needs a lot of cleanup. As a next step I want to implement simple certificate caching so accepted certificates won't get prompted again. This will be memory only at first, making the certificate valid (or invalid) as long as the dpid lives.
The updated patch is attached below.
A long time ago, browsing was mainly fetching pages and images. It made a lot of sense to use an external tool (as wget) to grab https pages. Implementing this idea with dpi was also simple. Now, it may be not the case. You have to keep track of certificates, sessions, sometimes keep an open connection, etc. Years ago SSL wasn't widespread, today is an everyday need, so it may make sense to consider having it inside dillo. It can take some design time at the beginning but will be easier to maintain and extend than to have it living in an external dpi. Developers is what we need, so if you want to work on https, you're more than welcome. Lack of manpower is our biggest problem! "place" implemented gzip decoding in dillo2, he may help you with ideas on how to add an extra layer/decoding-stage for SSL. (With regard to your specific questions about https, you'll have to wait some time until I can look at it again in depth. IIRC there was a five option dialog requested through dpip that sent the answer back on what to do. It was removed from the code while porting, delayed for future implementation). Again, my suggestion is to consider an internal implementation. -- Cheers Jorge.-
Hi Jorge, * Jorge Arellano Cid <jcid@dillo.org> [080315 18:58]:
Sorry for the late answer, but I've had little spare time, and several topics to answer.
Probably you have already read:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.htm...
an got some info from there.
Yes, thanks for the hint, it was insightful. I have spend a few thoughts on the SSL issue and I'd like to hear your opinion on it. The most work that still needs to be done is to handle certificates and the user interaction required to make it usable. The user needs to add trust values to certificates and to add or remove them offline. I think this can fit well into a server dpi. Adding and deleting bookmarks could be done similar to handling bookmarks. Which might be a bit rough but is independent on fltk widgets. I do think that we already have enough dialog types in dillo. Hard coding the certificate handling would not make the situation any better. Also I can imagine this plugin to handle client certificates which I do believe will become a more common requirement for certain applications in the future. Adding secure storage capabilities will be easy. Also people will have the chance to write some "bridging" plugin that extracts the needed data from existing storage sources elsewhere, i.e. certificate servers,... Handling this all internally means that we put functionality into dillo that are needed for, but basically have nothing to do with browsing. As I have grasped the spirit of this project this may not be the way to go. A nice thing about handling https internally is the opportunity to reuse an established connection for more than one request, which might speed up transfers significantly. But on the other hand couldn't this be done by dpid for all filter plugins? Dpid can keep them alive as long as the following requests belong to the same URL, then closing the connection after a timeout? I am sorry if this has been already decided on before. These thoughts were rumaging aroung my head all day now... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote:
Hi Jorge,
* Jorge Arellano Cid <jcid@dillo.org> [080315 18:58]:
Sorry for the late answer, but I've had little spare time, and several topics to answer.
Probably you have already read:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.htm...
an got some info from there.
Yes, thanks for the hint, it was insightful. I have spend a few thoughts on the SSL issue and I'd like to hear your opinion on it.
Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html
The most work that still needs to be done is to handle certificates and the user interaction required to make it usable.
Garret wrote a good part of the certificate handling, you will find that code inside the plugin.
The user needs to add trust values to certificates and to add or remove them offline. I think this can fit well into a server dpi. Adding and deleting bookmarks could be done similar to handling bookmarks.
Yes.
Which might be a bit rough but is independent on fltk widgets. I do think that we already have enough dialog types in dillo. Hard coding the certificate handling would not make the situation any better.
That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again.
Also I can imagine this plugin to handle client certificates which I do believe will become a more common requirement for certain applications in the future. Adding secure storage capabilities will be easy. Also people will have the chance to write some "bridging" plugin that extracts the needed data from existing storage sources elsewhere, i.e. certificate servers,...
I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar.
Handling this all internally means that we put functionality into dillo that are needed for, but basically have nothing to do with browsing. As I have grasped the spirit of this project this may not be the way to go. A nice thing about handling https internally is the opportunity to reuse an established connection for more than one request, which might speed up transfers significantly.
But on the other hand couldn't this be done by dpid for all filter plugins?
For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that.
Dpid can keep them alive as long as the following requests belong to the same URL, then closing the connection after a timeout?
I am sorry if this has been already decided on before. These thoughts were rumaging aroung my head all day now...
I hope these lines help. -- Cheers Jorge.-
Hi, I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/". As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo. This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there. Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 (with cookies enabled.) :-P On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote:
Hi Jorge,
* Jorge Arellano Cid <jcid@dillo.org> [080315 18:58]:
Sorry for the late answer, but I've had little spare time, and several topics to answer.
Probably you have already read:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.htm...
an got some info from there.
Yes, thanks for the hint, it was insightful. I have spend a few thoughts on the SSL issue and I'd like to hear your opinion on it. The most work that still needs to be done is to handle certificates and the user interaction required to make it usable. The user needs to add trust values to certificates and to add or remove them offline. I think this can fit well into a server dpi. Adding and deleting bookmarks could be done similar to handling bookmarks. Which might be a bit rough but is independent on fltk widgets. I do think that we already have enough dialog types in dillo. Hard coding the certificate handling would not make the situation any better.
Yes, dpi bookmarks have proven quite useful a model for this local data-handling case.
Also I can imagine this plugin to handle client certificates which I do believe will become a more common requirement for certain applications in the future. Adding secure storage capabilities will be easy. Also people will have the chance to write some "bridging" plugin that extracts the needed data from existing storage sources elsewhere, i.e. certificate servers,...
I assume you know more than me about this topic, so feel free to design a simple way to handle it. AFAIS it looks OK.
Handling this all internally means that we put functionality into dillo that are needed for, but basically have nothing to do with browsing. As I have grasped the spirit of this project this may not be the way to go. A nice thing about handling https internally is the opportunity to reuse an established connection for more than one request, which might speed up transfers significantly.
I'm not sure on which model will end up being simpler. I'd suggest to design on paper and test the basics before going for a full implementation. HTH. -- Cheers Jorge.-
On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote:
Hi,
I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/".
As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo.
This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there.
Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
(with cookies enabled.) :-P
I'm not too worried about that. First, there is still developers focused on fltk2. Second, if eventually fltk-1.3 (or whatever it will be called) should turn out to be better supported, more stable, or have important features I think we can port dillo-fltk over within one or two weeks. Cheers, Johannes
On Fri, Apr 11, 2008 at 02:50:03PM +0200, Johannes Hofmann wrote:
On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote:
Hi,
I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/".
As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo.
This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there.
Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
(with cookies enabled.) :-P
I'm not too worried about that. First, there is still developers focused on fltk2. Second, if eventually fltk-1.3 (or whatever it will be called) should turn out to be better supported, more stable, or have important features I think we can port dillo-fltk over within one or two weeks.
Funny how my sentence had at least two reads! :-) I agree with you, but what I was trying to say is that dillo2 freezes (i.e. gets into a non-resposive state) if you have cookies enabled for www.fltk.org and you start it with that URL. :-) -- Cheers Jorge.-
On Fri, Apr 11, 2008 at 10:02:55AM -0400, Jorge Arellano Cid wrote:
On Fri, Apr 11, 2008 at 02:50:03PM +0200, Johannes Hofmann wrote:
On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote:
Hi,
I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/".
As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo.
This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there.
Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
(with cookies enabled.) :-P
I'm not too worried about that. First, there is still developers focused on fltk2. Second, if eventually fltk-1.3 (or whatever it will be called) should turn out to be better supported, more stable, or have important features I think we can port dillo-fltk over within one or two weeks.
Funny how my sentence had at least two reads! :-)
I agree with you, but what I was trying to say is that dillo2 freezes (i.e. gets into a non-resposive state) if you have cookies enabled for www.fltk.org and you start it with that URL. :-)
Ahh, that freeze you mean :-) Cheers, Johannes
participants (4)
-
Christian.Kellermann＠nefkom.net -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org