On Sat, 25 Oct 2003, Madis Janson wrote:
I read the https.c included in dillo/dpi and seams, that it just gets url and and dumps html.
Yes, it's basically a dpi filter plugin.
What about content-type, cookies and POST requests? Since https is http over ssl, it seems natural to use dillo's http protocol implementation for these things (like i did with my https proxy for dillo), but is it possible with dpi?
Also, there seems to be one process for one connection, which makes hard to implement SSL session cache.
Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns:
Also, there seems to be one process for one connection, which makes hard to implement SSL session cache.
Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo).
content-type
(as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server.
Cookies
Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone.
POST
POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl.
Since https is http over ssl, it seems natural to use dillo's http protocol implementation for these things (like i did with my https proxy for dillo), but is it possible with dpi?
Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-