On Mon, Nov 12, 2001 at 10:59:14PM -0800, sterling wrote:
> Hi -
>
> I still have an outstanding bug (and patch) that hasn't gotten a response.
> I consider it a showstopper. Given the current default config simply add
> a <Location /> stanza with auth enabled and that triggers the bug I
> reported previously (the one where headers filters are never called).
Try this patch on for size (my tree is non-buildable since I synced
up). The thing here is that we walk up the request tree when we see
a non-HTTP_OK code. So, if we were to save the request_rec* BEFORE
we walk up the tree, I think we end up with the correct request_rec
and save some time to boot.
> There is a workaround - to disable the ErrorDocument stuff - but still, it
> seems to me like it should at least be double checked before 'beta'.
FWIW, the only thing I see stopping a beta is a segfault. Anything
else, I don't give a rats ass about. =) And, *especially* if there
is a workaround. Because at this point, 2.0.29-dev is
non-buildable, so I think it is unlikely we can get 2.0.29 out in
a reasonable time-frame. Remember, beta != bug-free. -- justin
Index: modules/http/http_request.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.118
diff -u -r1.118 http_request.c
--- modules/http/http_request.c 2001/11/11 22:31:03 1.118
+++ modules/http/http_request.c 2001/11/13 06:10:41
@@ -123,6 +123,11 @@
int error_index = ap_index_of_response(type);
char *custom_response = ap_response_code_string(r, error_index);
int recursive_error = 0;
+ /* There are some cases where we walk up the request hierarchy
+ * to obtain the original error, but when adding the required_filters,
+ * we need to do so against the one we came in with. So, save it.
+ */
+ request_rec *cur = r;
if (type == AP_FILTER_ERROR) {
return;
@@ -223,7 +229,7 @@
custom_response);
}
}
- add_required_filters(r);
+ add_required_filters(cur);
ap_send_error_response(r, recursive_error);
}
