httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Wells" <>
Subject RE: mod_include_post...the saga continues
Date Fri, 27 Aug 2004 22:40:46 GMT

The short and sweet of it is that it works.

I created a new entry in my filter context for bbcopy and had to do some
fancy foot work between the input_filter_handle and out_filter_handle
function calls.  I never could get request_config to work.  I wonder if
there was some other filter that was modifying this field?  Oh, bbcopy was
never recreated if r->request_config was not null, but since the data was
erroneous, it didn't matter.

I also saw, what I would call a lot of interesting and strange behavior.
I'll describe some of my findings later with this exception:  Immed. after
mod_include finishes parsing and including, there is a final call to my
input_filter function.  (I believe this occurs only if there is no request
body content.)  Does any one know why on earth this call would take place?
It seems like a good waste of processing.

I'm still debating whether to check all of this and to just flatten the
bloody bucket brigade and dump it into r->notes.  (I like r->notes.)  It
would save me a lot of concern over the many brigades that get created over
the filter's lifespan.

Anyway, Joe, we can discuss this new param bucket brigade in more detail
later.  Now, it's time to celebrate!


-----Original Message-----
From: news []On Behalf Of Joe Schaefer
Sent: Friday, August 27, 2004 2:02 PM
Subject: Re: mod_include_post...the saga continues

"Anthony Wells" <> writes:

> Nick had recommend that I use the request_config field to store the
> to the bucket brigade copy.


> I have done so, but when I go to retrieve the brigade and try to get it's
> length, I get some nasty segmentation faults.  Also, I have removed any
> other code from my module that uses r->request_config, so it should be
> untouched as far as I can see.
> My question is, Is the bucket brigade or buckets in my "copy" being
> up to soon?

Not that I can see from what you've posted.  Are you sure the bbcopy
your output filter receives from ap_get_module_config isn't NULL?

> Here is my code in my InputFilter module:
> 		apr_bucket_brigade *bbcopy;
> 		bbcopy = apr_brigade_create(f->c->pool, f->c->bucket_alloc);
> 		apr_bucket *e;
>     		for (e = APR_BRIGADE_FIRST(bb);
> 		     e != APR_BRIGADE_SENTINEL(bb);
> 		     e = APR_BUCKET_NEXT(e))
>     		{
> 	        apr_bucket *c;
>         	  apr_bucket_copy(e, &c);
>         	  APR_BRIGADE_INSERT_TAIL(bbcopy, c);

My only crticism of this code is that you're recreating bbcopy each
time your input filter is invoked (assuming that's where it is).
What you should be doing is using the filter's ctx slot to
hold a pointer to your bbcopy brigade, append the copied buckets to
that.  The opening logic in your filter would look like

    apr_bucket_brigade *bb_copy;

    if (!f->ctx)
        f->ctx = bb_copy = apr_brigade_create(f->r->pool,
        bb_copy = f->ctx;


> Here is my code in my OutputFilter module:
> 	apr_bucket_brigade *bbcopy;
> 	bbcopy = ap_get_module_config(r->request_config, &include_module);

Check that this is non-NULL (yes it can happen).

Joe Schaefer

View raw message