Bug 35166 - ap_send_error_response ignores status returned by handler
Summary: ap_send_error_response ignores status returned by handler
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0.54
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2005-06-02 02:55 UTC by Neil Schemenauer
Modified: 2009-08-29 21:20 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Neil Schemenauer 2005-06-02 02:55:38 UTC
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.
Comment 1 Nick Kew 2009-08-29 21:20:40 UTC
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.