https://bz.apache.org/bugzilla/show_bug.cgi?id=56984
--- Comment #10 from Yann Ylavic <[email protected]> --- (In reply to gmoniker from comment #9) > But is there any reason not to flush the response data and log the > transaction immediately after processing a client request? Instead of pool > destroy, the worker could call a flush after processing one client request. That would, I think, defeat the main goal of pipelining which is: fill in the pipe. > > Even if this is expected behaviour, and given that the PHP handler is doing > it wrong by depending on the previous request cleanup having been completed > when entering the processing of a new client request, it seems kind of > strange that output, and memory of one script is held back and only flushed > dependent on circumstances that are completely extraneous to it. The circonstance is precisely that the next (pipelined) request is already here when the current request is done, otherwise the flush is done (see the test on !c->data_in_input_filters in ap_process_request(), or in MPM event the test on c->data_in_output_filters so that all data get written before entering keepalive state). IOW, the current implementation considers pipelined requests should be answered with pipelined responses, as much as possible. > > If for example follow-on processing causes a segfault and no response was > sent yet by the first script to the client, the client will believe that the > script never finished. So this behaviour seems to run counter to the > expectation of stateless requests. Given that the user of a browser does not > usually have much control of whether his browser uses pipelined connections > or not, he cannot be said to have made a conscious choice for stateful > behaviour. If some process crashes, I'm not sure the client should rely on the number responses it actually received to deduce any state on the server side, it solely depends on whether the requests sent were idempotent or not (IMHO). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
