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. Cheers, -g -- Greg Stein, http://www.lyra.org/
