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