On Thu, Oct 04, 2001 at 09:09:46PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > I'm always of the opinion that bailing out is a correct way to go. It's > possible that the ssl_io_hook_read be registered directly with (Open)SSL to > perform the read/write operations - in which case, bailing out is a better > alternative.. Whatever..
Well, I don't see how ssl_io_hook_read could read from the socket anymore. =) So, that argument is kind of moot. I really don't like the fact that it sets errno - the caller (churn_input) never checks errno or does anything with it. I'd like to delay doing as much as I can with this function until after the filter is working. I'll revert NULL check in my tree. We can deal with this function later... > [snip] > Any errors such as these will be handled by CORE_IN and it will > pass back the correct error code. mod_ssl shouldn't do anything > here. Remember, previously, it had to handle all of the socket > code - that is gone now. > [snip] > > Tell me if I'm missing something or my eyes are playing tricks here.. Except > for the if (len == 0) loop, I don't see anything much that's missing from > here.. If that's what you're referring, then fine. Previously, the bucket that mod_ssl was reading from was the socket bucket (which also had an indeterminate length). We have now changed the rules so that indeterminate length (i.e. -1) buckets can't be passed outside of the core. You should only assume that you are getting bytes that were *already* read off the socket. The EAGAIN/EOF/etc checks aren't really possible given that. If an EOF is returned, we'll never hit this code. (Yes, this is sort of an implementation assumption - that we're not getting the socket bucket back, but I think it is a fair one to make.) > This trick doesn't get you anything if you look at the code path. > The renegotiation is handled by the process_connection hook. > [snip] > > '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? If renegotiating is occurring, then shouldn't there be 0 bytes to read? What was there (i.e. set readbytes to 0 to "trick" http_filter) - doesn't make any sense to me. If you can help me understand, why we have to explicitly handle this, I'd like to be enlightened. > I generally don't like the idea. It's really a *great* thing to have for > HTTP filters.. But, I have some concerns : > Some applications may legitimately ask for x bytes, some may ask for a upper > limit of x bytes, and some other may want to have all the data in the > channel (SSL).. I don't believe that is correct - retreiving all of the bytes in the channel (i.e. readbytes == -1) seems kind of bogus - it breaks all of the abstractions and can easily cause a DoS (as Greg pointed out). My understanding is that you are asking for x bytes. You may get x bytes, or you may get <x bytes back. And, while you could ask for -1 bytes, you are also (via our implementation) closing the connection and forcing an EOS to be sent. I don't think that is what is desired here under any circumstances within our server. > 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 > interpretation of the data has to be minimal.. > It may so happen that a protocol is designed such that it first reads all > the data available and then starts operating on it. I agree that it may be a > bad design - but the requirements may be such - are we telling that such > applications *cannot* work with Apache ?.. It can just read, but it has to read it in chunks that it determines. A connection-based filter has the option of buffering the data that it hasn't returned but has already processed. > Also, consider the performance impact that this would have on the SSL > transactions - take the case of a busy site where ssl data + certificates is > of length 2k (some random size > 1024).. For each transaction, the > SSL_accept is called atleast once more than the current model (because of > the lack of data given to it).. Taking into account how costly each SSL > call can be, the new method would be introducing a substantial amount of > delay. The SSL performance of Zeus webserver is something like 3x of Apache > - every extra transaction in Apache matters. (I'm not trying to get into > Zeus/Apache comparision here, but I'm just trying to see where Apache+SSL is > heading towards). I chose 1024 out of thin air, but that is also what ssl_io_hook_read reads in one loop in the input filter (buf is 1024 characters). If you have a suggestion on how to improve this number, I'm all ears. I'd like to be able to avoid the pmemdup if at all possible. I believe we have to read from the core in determinately-sized chunks. I don't think we can just say, "Give me everything." > I'll probably to go thru' another round of learning filters.. I think we all are. =) So, join the club... Ryan, Roy, and Greg have this all worked out in their heads. =) I'm just fumbling along - anything they say overrides whatever comes out of my mouth... -- justin
