DO NOT REPLY [Bug 41960] - Apache is not using custom content-types when accessing content-negotiated resources

[bu...@apache.org]

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 jose@w3.org  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org