Stas Bekman wrote:
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 didn't realise that mp2 doesn't use send_http_header. That explains
the appearance of wb->r->content_type in the mp2 code.
I'm not quite happy yet about the current situation with send_http_header API removal. Currently an explicit call to $r->content_type (only in mod_perl handlers) turns the headers parsing off, if it was on. Which works fine as a replacement for $r->send_http_header. However it's possible that some earlier phase calls $r->content_type and the response phase still wants to *print* its headers, rather than use API to set them. If that's the case, we are in trouble.
I'll be soon working on providing the API for PerlOptions and other config options. And while most of these things are read-only, I'm thinking that I might be able to add a read/write accessor for ParseHeaders. So one can turn the parsing on and off, disregarding what was the setting in httpd.conf. I believe that would be the perfect solution, since it'll give developers a total flexibility.
So is it true that if headers are sent using the API then no output filtering and transmission occurs until the 8k buffer is either filled or flushed (explcitly or after exit)?
That's correct. Though the headers are really sent by the Apache core http output filter, once we send the response body.
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.
Is +ParseHeaders always indicative of explicit header printing, or can it also be set when using the API? If the former, then yes, if +ParseHeaders is set flushing could be held off until a blank line is seen.
See my plan and current situation explanation above.
Do we now agree that the event of "end of sending headers" is possible only in the case explained at the top?
Yes, the key I was missing is that mp2 no longer uses send_http_header. Can you just lock out flushing when nothing has been printed and content_type is undefined? (You impliy above that the content_type setting is persistent, so the script would have to undef it if necessary.) Then all the user script has to do is to make sure any Status header is either printed or set via headers_out in the first batch of printing/setting code before flush is called (again).
As I suggested earlier, I think the solution is to ignore rflush calls if we expect to parse headers and they weren't parsed yet. However if the buffer overflows, we have not much choice but to send it out. But I think that this will be a satisfactory solution.
Also since close($fh) always flushes in mod_cgi, I think you can get rid of the explicit flush for good. Since mod_perl's CLOSE is no-op, it won't cause the flush (at least for now).
__________________________________________________________________ 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
