On Fri, Nov 19, 1999, Eli Marmor wrote:

> > > Is there any way to access the current request_rec from hooks like
> > > "ap::buff::write", "ap::buff::read"?
> > 
> > Sure, read README.dsov.fig carefully!
> > There the internal structure of Apache+mod_ssl+OpenSSL
> > is shown in detail.
> > 
> > In short:
> >    BUFF => ctx => request_req
> > 
> > In code (without error checks):
> >    ssl = ap_ctx_get(buff->ctx, "ssl");
> >    req = (request_rec *)SSL_get_app_data2(ssl);
> 
> Thanks!  Next time I must RTFS before posing questions...
> 
> Anyway, I have some more EAPI questions:
> 
> 1. I've looked for examples of similar code in the source, and found
>    that the returned value of SSL_get_app_data2(ssl) is ap_ctx, and
>    it must be passed to ap_ctx_get(actx, "ssl::request_rec") in order
>    to get the request_rec. Isn't it needed, or you just used a short
>    way when you wrote your message and didn't want to detail
>    everything?

Ops, sorry. Yes, my fault. You first get an ap_ctx and then
out of it the request_rec. So the correct way to travel
from an BUFF* to a request_rec* is:

   ssl = ap_ctx_get(buff->ctx, "ssl");
   ctx = (ap_ctx *)SSL_get_app_data2(ssl);
   req = (request_rec *)to ap_ctx_get(ctx, "ssl::request_rec");

> 2. I'm looking for a way to be notified when a BUFF is closed (or in
>    other words: "ap::buff::close", just like "ap::buff::read" and
>    "ap::buff::write"). Is there anything?  Or should I use the
>    close_connection_hook() and access the c->client from there?  Or,
>    a third option, just insert my hook as a patch into buff.c?

Currently there is no ap::buff::close, but it could be added easily as a new
EAPI hook to buff, yes. But OTOH the close connection hook actually is
triggered in Apache always directly before the ap_bclose, so you can use this
one instead.

> (if anybody is curious, what I'm trying to do is just using EAPI for
> generic filter for HTTP documents. Sometimes a parser must look ahead
> before being able to decide what should be done with the contents
> passed through it, and in the next write hook call, the following
> contents resolve this question. But sometimes there is no more write,
> but the BUFF is closed, so the contents waiting for the next write
> must be flushed).

Ah, a little bit similar to the problem I had to solve for POST request and
reads inside ssl_engine_io.c. Interesting.
 
> BTW: My messages reach the list after a delay of MANY hours. It means
> that I'm recognized as a user who is not subscribed to the list. But
> I am subscribed. Can it be fixed?

No, your messages are not bounced to my admin accounts for approval.
So your delay has to occur somewhere else, perhaps at your ISPs.

                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [EMAIL PROTECTED]
Automated List Manager                            [EMAIL PROTECTED]

Reply via email to