> IMHO, that's a design flaw. Regardless of whether PHP is doing
> buffering, it shouldn't break up blocks of static content into
> small pieces--especially not as small as 400 bytes. While it's
That sounds like the input size of the lexer which is a part
which I'm not particularly proud of.
> certainly valid for PHP to insert a flush bucket right before a
> block of embedded code (in case that code takes a long time to
> run), breaking static text into 400-byte chunks will usually mean
> that it takes *longer* for the content to reach the client, which
> probably defeats PHP's motivation for doing the nonbuffered output.
> There's code downstream, in the httpd's core_output_filter and
> the OS's TCP driver, that can make much better decisions about
> when to buffer and when not to buffer.
I doubt that core_output_filter knows the script author's
intentions very well. Anyway, Aaron and Cliff posted a patch
which was committed by Sebastian in mid-April which
introduced this behaviour.
/* Add a Flush bucket to the end of this brigade, so that
* the transient buckets above are more likely to make it out
* the end of the filter instead of having to be copied into
* someone's setaside. */
b = apr_bucket_flush_create(ba);
APR_BRIGADE_INSERT_TAIL(bb, b);
The need for this should be reassessed. Aaron/Cliff, can you
please have a look at this?
Please keep in mind that script authors can always use
flush() to insert the flush-bucket.
- Sascha
