httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: [PATCH] SSL, POST, and renegotiation
Date Tue, 11 Jun 2002 00:31:26 GMT
> 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

Mime
View raw message