httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] mod_ssl input filtering...
Date Fri, 05 Oct 2001 05:43:34 GMT
On Thu, Oct 04, 2001 at 08:12:42PM -0700, Justin Erenkrantz wrote:
> On Thu, Oct 04, 2001 at 09:09:46PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> > 'not necessarily. The renegotiation request can come from the
> > ssl_hook_Access() also - in which case ssl_hook_process_connection has no
> > business whatsoever..
> What is the deal if renegotiation is set?  It doesn't do anything
> of interest, does it?  Why can't OpenSSL handle this transparently?

To renegotiate, OpenSSL must send data to the client. Since OpenSSL doesn't
have a socket, it needs the help of mod_ssl to deliver stuff to the client.
That is why the input/output filters are tied together -- you try to read,
need to renegotiate, send data to the client, read the result.

[ caveat: this is only based on something that I recall Ben saying once ]

> > I'm a novice here and 'obviously missing something - can somebody tell me
> > why should a application not be given whatever it's asking for - especially
> > if it's geniune (think SSL) ?..  Also, I guess there has to be a
> > differentiator b/w a protocol and a application here.. A protocol should to
> > be given all the data it asks for (and in the format it asks for) - the

Nope. It asks for X and we'll give it *up to* X. If the app doesn't get the
full X, yet it wants more, then it can always call again for more data. This
is standard behavior for non-blocking systems (e.g. sockets and pipes).

> I believe we have to read from the core in determinately-sized 
> chunks.  I don't think we can just say, "Give me everything."

Absolutely. The -1 mode can kind of do that, but it is so far beyond bogus
that we should not be building mod_ssl that way :-)  Therefore, you have to
have some kind of buffer size for reading from the next filter.


Greg Stein,

View raw message