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=41960>. 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=41960 ------- Additional Comments From [EMAIL PROTECTED] 2007-05-11 20:25 ------- Following your suggestion, and after doing some tests, I applied the following patch to server/request.c: [[ *** /tmp/request.c Sat May 12 04:54:31 2007 --- ./request.c Wed Jul 12 05:38:44 2006 *************** *** 152,161 **** return access_status; } ! /* Rerun the location walk, which overrides any map_to_storage config. */ ! if ((access_status = ap_location_walk(r))) { ! return access_status; } /* Only on the main request! */ --- 152,165 ---- return access_status; } ! /* Excluding file-specific requests with no 'true' URI... */ ! if (!file_req) { ! /* Rerun the location walk, which overrides any map_to_storage config. ! */ ! if ((access_status = ap_location_walk(r))) { ! return access_status; ! } } /* Only on the main request! */ ]] This solves the problem I originally stated, when using the plain-vanilla apache. Could you confirm if this patch works for you too (without any side effect)? request.c:ap_process_request_internal() does two conditional evaluations using filereq. By doing tests, I saw that the the patch worked when suppressing it in the second conditional evaluation. I didn't notice any difference in behavior if I supressed it in the first evaluation too. I'm not sure if you had proposed suppressing all filereq evaluations throughout all of request.c:ap_process_request_internal(). In all cases, one of the consequences of keeping the first evaluation, is that ap_translate_name() won't be called when evaluating subrequests... and maybe this is not good. I was unsure on how to translate the code differences between apache1.3.37 and apache2.2.4. Apache 1.3.37 returns calls ap_die() for some of the functions functions that are inside these evaluations, where apache2.2.4 just does a return access_status. Is it equivalent in the new architecture? Could you confirm if this patch works for you (without any side effect)? Or provide further advice? I'm willing to continue testing and trying code changes. When I add our custom aaa modules, I've a side-effect where some of the previously authorized requests that returned HTTP 200, are now giving back HTTP 403. This may come from work arounds I had added to copy the request's context. I will look at this in some days and report again. Thanks! -jose -- 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]
