Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: Using libapreq from ISAPI filter
Date: 05 Jan 2004 17:33:35 -0500
Lines: 57
Message-ID: <87znd2t48w.fsf@gemini.sunstarsys.com>
References: <bt1i9l$7nj$1@sea.gmane.org> <btc8le$p7b$1@sea.gmane.org>
 <874qvautib.fsf@gemini.sunstarsys.com> <btcdsc$5b5$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news <news@sea.gmane.org>

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