The cause of the problem was my perl code calling flush.pl and flushing STDOUT at a point prior to it printing the response headers. Under mp2, flushing STDOUT calls mpxs_output_flush in xs/Apache/RequestIO/Apache__RequestIO.h, which in turn calls ap_rflush, which triggers creation of the HTTP header, which at this stage, prior to my script printing its 302 header, uses a 200 OK status.
Meaning no offence to the mp2 developpers, I find this observed behaviour inappropriate - I recently have to develop a reverse-proxy and got bitten by undocumented semantics of this sort every so often, I had to resort to reading the source with pencil & paper like the original poster apparently did.
I think you are confusing mp2 design with Apache2 design. This is how Apache2 works, the main reason I believe to accomodate the filtering mechanism.
As for undocumented behavior, you are welcome to submit documentation patches or wait till someone will write them.
What is the architectural justification for not choosing one of those two behaviours about header output, and erring on the middle side:
* headers are out-of-band, and the first call to print() prepends whatever headers were set using the appropriate API (e.g. print_header() should have no effect afterwards, or maybe should set HTTP/1.1 trailers);
That's exactly how it works. The first print/puts/printf/rflush causes the headers to be sent (assuming that STDOUT is unbuffered), using whatever headers were set so far. Do I miss something here? This is 1:1 mapping to Apache behavior.
The only difference is the mod_perl internal STDOUT buffer used for buffered STDOUT.
* headers are regular flow, and Apache / mp2 never tries to add its own ones (almost impossible to ensure under Apache / mp1).
Thanks for any insight on this topic - maybe there is a FAQ somewhere about MP2 architecture ?
There are Doug's architecture notes online, I did some changes to them to bring things to the current state of things. They are certainly could have some more work. Patches are welcome.
__________________________________________________________________ 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
