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.-