>
> 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.
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);
* 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 ?
--
Dominique QUATRAVAUX Ingénieur développeur senior
01 44 42 00 08 IDEALX
