perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Mon, 19 May 2003 23:47:47 GMT
Stas Bekman <> writes:


> This is going to be a problem, btw. How users are going to trigger
> that "tee"? 

By calling Apache::Request::new().  The filter is passive-aggressive,
which means it pulls nothing in all by itself.  It just passively
copies buckets in the input brigade and hands those buckets off to
the parser.

The filter only prefetches if someone calls Apache::Request::param, 
and the underlying apreq_param() function cannot find the key among 
the already-parsed data.  In that case, it prefetches data via 
AP_MODE_SPECULATIVE mode, parses what it gets, and then later skips
the prefetched data during normal AP_MODE_READ operation.

> If someone needs to read the POST data in the pre-response handler,
> can they do it? What if response handler injects a new input filter?
> How do you ensure that apreq is injected on the very top?

With code, if we really require that :-).  I don't think we do though,
just look at the AP_MODE_SPECULATIVE support in httpd's core input filter.

> I think that by default apreq should work as before, simply sucking
> the POST data on demand. 

It still works just as before. The only difference is that with
the filter, we do *less* not more.  In apreq-1, a call to
Apache::Request::param induces a full parse of the POST data.
We no longer do that- we simply can't.  It amounts to the same 
complaint I have with $r->content as a request note.

> Only if a user configures it as an input filter, they have to have an
> explicit control over it, i.e. they have to use the mod_perl API to
> insert that filter explicitly.

No- the filter just goes in as needed, and it just plain-old works.
The end (perl) user should not care one iota about how apreq is

Joe Schaefer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message