This bug appears to affect both Apache 1.3 and 2.x. I think the core problem is that ap_send_error_response sometimes ignores that status code returned by the handler function and uses r->status_line instead. For example, ap_scan_script_header_err_core may return a status of 304 (from ap_meets_conditions). The problem is that r->status_line may have been set by a "Status" header. An example CGI script that triggers the bug: print "Status: 200 OK\r\n" print "Context-Type: text/plain\r\n" print "Last-Modified: Thu, 14 Apr 2005 00:10:07 GMT\r\n" print "\r\n" print "Hello world.\n" The ugly effect of this bug is that Apache can send 200 as the status when it thinks it is sending a 304 response. It does not send a Content-Length header and the browser and server end up hanging. I've tested this with a CGI script like the one above, Apache 1.3, and Firefox 1.0.3. I'm fairly sure recent versions of Apache have the same bug.
Hmm, I recollect fixing something very like this some years back, and a quick test of your script shows the CGI Status being respected. Marking fixed. Please reopen with details if I'm missing your point. The script is itself somewhat broken, in that it returns 200 when 304 would be in order. But that's a different story, and not apache's business.