httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Using libapreq from ISAPI filter
Date Mon, 05 Jan 2004 22:33:35 GMT
Vladimir Dudov <dudov@relexus.com> writes:

> Joe Schaefer wrote:

[...]

> > The APREQ_ENV_MODULE's "request" function should be thought of as a
> > get/set call for the "active" request in a particular env.  By
> > active, I mean the apreq_request_t struct that will get its body
> > table filled in whenever the APREQ_ENV_MODULE's "read" is
> > subsequently invoked (read takes a void* as its first argument,
> > NOT an apreq_request_t*).
> >
> Will such implementation of "request" work?
> static apreq_request_t *myfilter_request(void *env, apreq_request_t *req)
> {
>     return req;
> }

That's probably not enough.  You need to allocate another 
apreq_request_t * (somewhere) and let your "myfilter_request"
function provide a get/set API for that pointer (internally
libapreq2 will want the return value from a call like 
myfilter_request(env, NULL), and providing a NULL here will usually
lead to a segfault.  Have a look at the default CGI environment
in src/apreq_env.c for a minimal implementation.

As with the CGI port, I think the trick will be to determine
an appropriate per-request (thread-safe in the IIS case) data 
structure.  With CGI we just needed the enviroment to yield
an apr_pool_t, since the other structures could be assigned
to a static global data structure.  So we made the CGI data
structure an apr_pool_t and ask the user to provide libapreq2
with the pool.  In apache2 we built everything around the
request_rec; we needed to be careful there about balancing it 
with apache2's filter API (which is why mod_apreq.c is so 
complicated).

> What is the best place to configure req->cfg?

Any time before the actual request parsing starts.  This month
I'd like spend more time cleaning up the cfg API (eliminating cruft like
max_fields and read_ahead, since they're totally unnecessary), so
suggestions/patches there are certainly welcome.


> My "read" function doesn't do anything (just returns APR_SUCCESS)
> because it's hard to provide data through the callback function in my case? 
> Is it Ok to supply all request data through the bb parameter to
> apreq_parse_request() instead of using callback "read"?

Sure, that's fine.  Again take a look at how we're doing CGI- "read" 
just appends an eos bucket to a brigade containing a socket bucket 
and lets the parser gobble it all up.

-- 
Joe Schaefer


Mime
View raw message