Item2521: Support early flush of some HTTP responses
With FSA we have lost the ability to flush a request while it is still partially complete. This has made some things easier - for example, post-processing of the response before send for things like SafeWikiPlugin - but at the same time it has crippled anything that relies on an early flush to report progress (e.g. MailerContrib
Note that when you fix this, you're going to have to consider the following:
- Some process may add to the header, even after the body has been partially generated - don't break Validation!
- Post-processing of the response in the
completePageHandler, e.g. SafeWikiPlugin
Anything attempting to output header fields after a flush has already happened has to be regarded as an error, and reported as such so it can be fixed.
Reporting this as Urgent against trunk because it really is a big problem, but retro-fitting it to 1.0.8 is likely to be impossible.
Note that it would be acceptable for an explicit
function to require that the header is complete at that point. It may
also be acceptable for many applications if a newline in the body triggered a flush (a la STDIO). However there are other applications where that would not
- 22 Dec 2009
I implemented a
function on the
. This function simply emits the headers if it needs to, and marks the response as partially complete. Any header modifications made after the response has been flushed will hit an ASSERT.
The way to use this is shown by the
- 10 Jun 2010
The HTMLvalidation unit tests don't like that. I don't really get why the request is in stdout and not in $response, at least not in full, but maybe CDot knows.
Anyway, making a fallback in the test, and that works great.
- 12 Jun 2010
The request? Surely you mean the response?
Anyway, the reason is that if a script uses
, then the response up to then is flushed to stdout. Otherwise it is cached to the end.
- 13 Jun 2010
and in the process breaking the unit tests on windows strawberry perl - may be a 5.12 benefit.. - fixing.
- 23 Jun 2010