perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Tue, 20 May 2003 00:15:27 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> 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
> implemented.

I haven't looked at the AP_MODE_SPECULATIVE yet :( I will.

My main concern that the above doesn't answer is how the apreq filter 
co-operates with other custom input filters. It has to be inserted on the very 
top, so not to miss any transformations on the request body, but Apache 
provides no API to ensure that a certain filter will be run very last (which 
is actually very first in the input-terminology).

I suppose that this somehow will work if apreq filter injects itself at the 
very last moment and the user has to be aware of how it works, so there would 
be no questions of why their POST data didn't go through their filter if they 
have inserted their custom filter after calling $apreq->param(foo) which has 
triggered POST read.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message