DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38070>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070 ------- Additional Comments From [EMAIL PROTECTED] 2006-02-03 01:39 ------- (In reply to comment #3) > Are you sure you don't want to convert a CGI-generated 200 to a 304 when the > HTTP conditions fail? There are two cases. If the CGI *explicitly* generates a Status: header, we should honour it. If not, then we just need to generate whatever is appropriate - usually 200, or 302 if the CGI emitted a Location header. > ap_scan_script_header_err is also called by mod_asis . I The crucial difference thare is that mod_asis isn't documented as having a Status header (though I guess it might, if it goes through the same parsing as CGI). > use mod_asis extensively, with files which include Last-Modified: and ETag: > headers, and it would be disastrous to return 200 when 304 would be appropriate. Your asis doesn't say "Status: foo"? Then the patch won't affect it. > > Admittedly, I've had to patch both mod_asis.c and util_script.c to get the right > results, but my server seems to return the responses I expect. If you're saying we've got something wrong in the patch, please explain. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
