From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728

Description of problem:
Apache return 200 to a client without HTML body, 2nd time client access cgi program. But in the access log, 304 is logged.

This problem has been reported since 2000.
http://archive.apache.org/gnats/5640
(patch is here)

http://issues.apache.org/bugzilla/show_bug.cgi?id=37166
(The sample cgi script is attatched in this case)


Version-Release number of selected component (if applicable):
httpd-2.0.52-12.ent

How reproducible:
Always

Steps to Reproduce:
1. Enable mod_cgi
2. Setup sample cgi script.
3. Clear browser's cache.
4. Access the cgi page.  
5. Access the cgi 2nd time. 


Actual Results:  1. The 1st access, "Hello World" is display.
   Status code 200 is logged in access.log.
   Status code 200 is sent to browser. (Observed by tcpdump)    

2. The 2nd access, blank page is display.
   Status code 304 is logged in access.log.
   Status code 200 is sent to browser. (Observed by tcpdump)    



Expected Results:  1. The 1st access, "Hello World" is display.
   Status code 200 is logged in access.log.
   Status code 200 is sent to browser. (Observed by tcpdump)    

2. The 2nd access, "Hello World" is display.
   Status code 304 is logged in access.log.
   Status code 304 is sent to browser. (Observed by tcpdump) 


Additional info:

This symptom is reported both Apache 1.X and 2.X.
As I patch following patchlet to stock apache 2.0.55,
it fix the problem.  So I request Red Hat to include it 
into your httpd RPM.  
I will be happy to test it.

http://archive.apache.org/gnats/5640
--- util_script.c.orig	Sun Jan 23 00:50:16 2000
+++ util_script.c	Sun Jan 23 00:50:55 2000
@@ -498,6 +498,21 @@ API_EXPORT(int) ap_scan_script_header_er
 	    ap_kill_timeout(r);
 	    if ((cgi_status == HTTP_OK) && (r->method_number == M_GET)) {
 		cond_status = ap_meets_conditions(r);
+		/*
+		 * If CGI script returned Status header 200 OK
+		 * and we ended up with cond_status which doesn't aggree
+		 * with it, we need to unset r->status_line, otherwise
+		 * ap_basic_http_header() would still send the status
+		 * in the form returned by CGI script, causing all sort
+		 * of possible lossage.
+		 * Note that r->status is correctly updated in case of
+		 * error by functions running module handlers, but doing
+		 * it here as well doesn't harm and improves readability.
+		 */
+		if (cond_status != OK) {
+			r->status = cond_status;
+			r->status_line = NULL;
+		}
 	    }
 	    ap_overlap_tables(r->err_headers_out, merge,
 		AP_OVERLAP_TABLES_MERGE);
XXX cut here XXX