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.
*/
AP_DEBUG_ASSERT(!APR_BRIGADE_EMPTY(bb));
Meaning your filter hasn't written anything.
Hmmm.
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
key1=FOO%D3D+I+SALUT+ARMATNI%3B%3B%3A%3A&key2=BAR%D3D+I+SALUT+ARMATNI%3B%3B%3A%3A
(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
incomplete.
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
&key1=FOO%D3D+I+SALUT+ARMATNI%3
(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.
