however, removing that logic causes api/lookup_uri2.t to fail, but I suspect this is an issue with puts() rather than the subrequest mechanism - changing puts() to print() makes everything work just fine. does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
rputs() never flushes data, print() flushes if $| == 1;
ah, ok, that's the difference.
So there is no problem with the r->main logic in mpxs_ap_run_sub_req, it's there for exactly this reason.
no, there is definitely something wrong. someplace :)
if I'm in a filter and call sub->run (which is what mod_include essentially does), mod_perl is silently passing along the data I'm in the middle of filtering. so, if the filter sees
data<tag>data
and wants to substitute something for <tag> via a subrequest, it won't work - mpxs_ap_run_sub_req is flushing <tag> along before the filter gets the chance to decide about the data.
as I said, nowhere in any of the module shipped with core do I find logic like this - mod_include and mod_cgi both seem to call ap_run_sub_req without flushing the main data stream (though mod_include does split the stream and send the data _prior to the tag_ off). I don't see why mod_perl needs to behave differently in this respect, but if flushing is required for other reasons I can't see, making it a tacit part of $sub->run seems the wrong solution since it goes against the intent of output filters.
and you forgot to add to the patch a new file #t/htdocs/filter/subrequest.txt core subrequest
yes, sorry.
> or even better:
out_str_subreq_default out_str_subreq_modperl
since these correspond to the SetHandler settings.
will do.
--Geoff
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
