> AFAIK, this situation isn't implemented yet for 2.x. Currently, the server
Yes, I got hit by the clue stick from Cliff. This is a special case where mod_ssl wants to empty its input. > > P.S. core_request_config->bb shouldn't be used at all. > > Oh, i see. May I ask for some general overview of reasoning here? How else > may the data be passed around, short of creating a hook or adding onto a > structure? It was my _guess_ that this could be used, since > ap_get_client_block() uses it already, no change would be required for that > function. core_request_config->bb is bogus in 2.0 as is ap_get_client_block (but I can't seem to convince Ryan of that yet). For true 2.0 modules should be using ap_get_brigade NOT ap_get_client_block. The only reason we're keeping ap_get_client_block() is to ease migration of 1.3 modules. As you sort of figured out, every other module and filter would have to be special-cased to re-read your data. What you want to do is trigger mod_ssl's input filter to read everything it can and then leave it there in its own brigade. When the next input call comes, it can deliver the data under the old encryption (but already processed by OpenSSL) as well as the new (unread) data. DougM rewrote a lot of the SSL input/output filtering to use BIO abstractions. What it seems you want to do is some special combination of: ssl_io_hook_read char_buffer_write HTH, but Doug may have better ideas since he knows the code a bit better than I do. -- justin
