The difference between mod_cgi and mod_perl is that mod_cgi does not activate the filter brigade until it has read all the headers.
But in the case of mod_perl, this "event" is valid only for handlers which print their own headers, rather than using mod_perl API to set them. In the generic case, there is no way to tell whether a handler is going to set more headers or it has done with it.
So can flushing be held off until either (1) blank line is printed, (2) the 8k buffer fills, or (3) send_http_header is called?
1) is relevant only for handler that print headers, rather than set them
2) absolutely not, what if you want to flush data before?
3) send_http_header doesn't exist in Apache2/mod_perl2
I suppose that we could prevent flushing in the case the handler is configured to parse headers. Does it make sense?
No. Could you explain your reasoning.
Only in the case that your handler is configured with:
PerlOptions +ParseHeaders
*and*
it prints headers ala:
print "Content-type: ...."
In all other cases where headers are set via the API, e.g. $r->content_type, $r->headers_out, etc, there is no such a thing as "the handler has send an empty line signaling the end of sending headers", because it never sends any headers at all, but uses api to set them.
Are we on the same page now?
mod_cgi uses spilling buckets, each of size 8K, to buffer script output,
including during the header scan, while mod_perl seems to scan the headers
when the first 8K buffer is either filled or flushed.
I don't think this is related to the issue in question. Since the problem is what to do on flush.
Also we might have a problem if the headers to parse are bigger than the size of the buffer (8k). Do you think someone will ever need to send headers bigger than 8k?
Yes, I mentioned the buffer size in case your objection to my proposal
to wait until end of headers was seen was based on the possiblity of
more than 8k of headers.
Again, the concept of "the end of headers" exists only in certain cases.
With the current mp2 code, if you decide to wait for the end of headers before doing cgi parsing and flushing then the code is assuming that either the headers are less than 8k or that any Status header is in the first 8k. Otherwise the code would have to be re-written to use continuous (spilling and merging) buffer buckets like mod_cgi. It can hold off on flushing indefinitely.
That approach will break this handler:
sub handler {
my $r = shift;
$r->content_type('text/plain');
$r->rflush; # send something to the client immediately
long_job();
return Apache::OK
}However notice that it doesn't have to set content_type() because some earlier handler could have done that and that should work as well:
sub handler {
my $r = shift;
$r->rflush; # send something to the client immediately
long_job();
return Apache::OK
}So as you can see, this handler doesn't tell us when it's done with headers.
OK, you may say that that previous handler should have marked the end of headers settings, but that would be wrong if the response handler wants to set other headers as well.
Do we now agree that the event of "end of sending headers" is possible only in the case explained at the top?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
