Very Computer

In an apache handler, we read request data using ap_get_client_block,
which can be used as a drop-in replacement for read or fread in
libraries that expect such functions as callbacks.

A more complex partial equivalent can be used in a filter - eg with
ap_get_brigade in an input filter. But it is limited to a single call
to a filter function that may be called multiple times.
So it can only be used as a callback with the aid of a hack, such as
reading all the data into memory (and there is no apr_realloc) or to
a tmpfile.  I can't see any really satisfactory fix for this.

The kind of thing I'm doing is exemplified by mod_xml.  In the main handler
I can do things like (illustrative pseudo-code):

  parser->read_callback = ap_get_client_block ;
  parser->run() ;

But I'm having trouble trying to do the same in a filter, particularly
an output filter where I most often want it!

Any suggestions?

--
Nick Kew

Available for contract work - Programming, Unix, Networking, Markup, etc.

I wrote a hack a while back that permitted multiple filters.  It
required a small change in one of the apache core files-- I forget the
details.  I could figure out no way to do it in Apache 1.3 without
such a change.  In 2.0 it may be possible.

I can dig out the code if you want it but it may take me a while.

Quote:> I wrote a hack a while back that permitted multiple filters.  It

With read()- compatible input?  It's not the number of filters I'm
interested in, but rather how any filter reads its input.

Quote:> required a small change in one of the apache core files--

That would rule it out for much, but not all, of what I want to do.
OTOH looking at your code with 2.0 might suggest a workaround.

(my alternative is to mess about with subrequests, but a filter should
be a much cleaner way to go).

Quote:> I can dig out the code if you want it but it may take me a while.

If it does what I'm asking then yes please!

--
Nick Kew

Available for contract work - Programming, Unix, Networking, Markup, etc.

I'm not sure I understand your question.  Maybe we're not talking
about the same thing.  Part of the problem is I don't remember exactly
what I did.  It was something a client wanted a while back; I did it
and mostly forgot about it afterwards.  But as I remember, it allowed
modules to edit and inject stuff into the POST data stream that cgi's
would then see.  So I guess it was read() compatible.  It worked
by adding an additional hook to the place where the 1.3 EAPI normally
attached the SSL stack to the read function.

Quote:> > required a small change in one of the apache core files--

> That would rule it out for much, but not all, of what I want to do.
> OTOH looking at your code with 2.0 might suggest a workaround.

I guess so.  Part of the issue was my hack had to work in conjunction
with SSL.  My patch was in one of the EAPI support functions.  But I
think in 2.0 they eliminated a the EAPI hair and made SSL a standard
module.

Quote:> (my alternative is to mess about with subrequests, but a filter should
> be a much cleaner way to go).

I don't think subrequests could do what I did.  Can you describe
your problem more fully?

Quote:> > I can dig out the code if you want it but it may take me a while.

> If it does what I'm asking then yes please!

It looks like it's on another machine that I won't be able to get to
real soon, but I should retrieve it sometime and I'll put it on my web site.
Remind me in about 2 weeks if I have done it by then.