https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW --- Comment #7 from Eric Covener <[email protected]> --- In both cases, you're bailing out at the bottom of the block below here, so r->status is not restored as it is later in ap_die: AP_DECLARE(void) ap_die(int type, request_rec *r) { int error_index = ap_index_of_response(type); char *custom_response = ap_response_code_string(r, error_index); int recursive_error = 0; request_rec *r_1st_err = r; if (type == AP_FILTER_ERROR) { ap_filter_t *next; /* * Check if we still have the ap_http_header_filter in place. If * this is the case we should not ignore AP_FILTER_ERROR here because * it means that we have not sent any response at all and never * will. This is bad. Sent an internal server error instead. */ next = r->output_filters; while (next && (next->frec != ap_http_header_filter_handle)) { next = next->next; } /* * If next != NULL then we left the while above because of * next->frec == ap_http_header_filter */ if (next) { ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "Custom error page caused AP_FILTER_ERROR"); type = HTTP_INTERNAL_SERVER_ERROR; } else { return; } } It seems like it might be safer to avoid r->status = HTTP_OK in the caller if the error is AP_FILTER_ERROR. (I think the error in the other branch looks wrong too, it does not yet know that that AP_FILTER_ERROR came from an errordoc creation / recursive call) -- 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]
