perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: generic question on input filters
Date Thu, 09 Apr 2009 11:38:49 GMT
Torsten Foertsch wrote:
> On Thu 09 Apr 2009, André Warnier wrote:
>> I have the impression that I am getting this Apache error :
>> [Wed Apr 08 22:46:22 2009] [crit] [Wed Apr 08 22:46:22 2009] file
>> http_filters.c, line 1324, assertion "!(((&(bb)->list))->next ==
>> (struct apr_bucket *)((char *)((&(bb)->list)) - ((long) (((char *)
>> (&(((struct apr_bucket*)((void *)0))->link))) - ((char *) ((void
>> *)0))))))" failed [Wed Apr 08 22:46:22 2009] [notice] child pid 5518
>> exit signal Aborted (6)
> Perhaps it's easier to implement a brigade based filter since this comes
> from here:
>     rv = ap_get_brigade(r->input_filters, bb, AP_MODE_READBYTES,
>                         APR_BLOCK_READ, bufsiz);
> ...
>     /* If this fails, it means that a filter is written incorrectly and that
>      * it needs to learn how to properly handle APR_BLOCK_READ requests by
>      * returning data when requested.
>      */
> Meaning your filter hasn't written anything.
So I cannot return "nothing" at any filter invocation.

Is there some hack allowing me to return "something" that will satisfy 
Apache, without introducing input data I don't want ?
(sending like a "null string" brigade, but brigade anyway ?).
Can I for instance do a $f->print('') ?

On the input side, I get a URI-escaped query string, like
(but much longer).
I want to unescape this data, replace some of the characters, then 
re-escape the data and forward it to the application.
Presumably, the input could be split over 2 bucket brigades, the first 
one ending at some "%" or "%3", leaving one trailing escape sequence 
I was trying to avoid that, by only processing "complete" query 
parameters "key=value" (which is also nicer for logging), but that of 
course can lead to the case where I have a brigade like
(with a yet-incomplete parameter, but nothing before it that I can process).
In that case, I was saving the string for later in $f->ctx, and 
forwarding nothing this time around.

Looks like I'll have to drop the idea of processing complete query 
parameters, and switch to processing complete escape sequences instead.
Or else, do a print of some dummy parameter which I know the application 
will ignore.  But that is a really application-specific hack.

View raw message