Red Hat Bugzilla – Bug 134764
mod_proxy does URL escaping twice
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041005 Firefox/0.10.1 Description of problem: URL escaping is done twice in mod_proxy. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13577 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15207 http://marc.theaimsgroup.com/?t=108791464300002&r=1&w=2 For us, with authentication enabled in a reverse proxied <Location> part, the request parameters get dropped. To us, this is a very bad bug and actually blocks a rollout. Version-Release number of selected component (if applicable): httpd-2.0.46-40.ent How reproducible: Always Steps to Reproduce: 1. setup apache to do reverse proxying to an url 2. protect the location with an authentication module 3. test with URLs with request parameters: apacheserver.local/myurl.do?id=444 Actual Results: apacheserver.local/myurl.do is forwarded, the parameters are dropped. See the above urls in the apache bugzilla for more info. Expected Results: Forward to apacheserver.local/myurl.do?id=444 Additional info:
Thanks for the report.
Bug report is misleading, it was another problem: If the auth module does authentication not with AuthType Basic, but through other means, if the "AuthType" is left out, the fixups for other modules, in this case the proxy module won't run. If "AuthType XXXX" with "XXXX" as some random/module depended string is added to the protected Location, it will work. Hope this helps. Maybe this should be documented somewhere. I have no information about the "twice escaping bug" I mentioned. As far as I am concerned, this bug can be closed as "invalid" or so.
Thanks for the further information. Can you post a complete <Location> block which triggers the bug, for you?
This is depended on the auth module, in our case, mod_auth_mda http://www.frogdot.org/ ------------------------------------------------ ProxyPass /myapp https://192.168.0.2/myapp ProxyPassReverse /myapp https://192.168.0.2/myapp <Location /myapp/> AuthName MDAAuth #AuthType MdaCookie Require valid-user MDARealmMask "0000000001" MDAAuthTimeoutURL "http://myhost/login" MDAAuthLoginURL "http://myhost/login" MDAAuthTimeoutMin 600 </Location> --------------------------------------------------- if AuthType is NOT there, it won't work, if it's there it will work. Reason: /usr/src/redhat/BUILD/httpd-2.0.46/server/request.c, ~line 234: if (ap_some_auth_required(r)) { if (((access_status = ap_run_check_user_id(r)) != 0) || !ap_auth_type(r)) { return decl_die(access_status, ap_auth_type(r) ? "check user. No user file?" : "perform authentication. AuthType not set!", r); } The module returns "OK", but the auth type is not set, the decl_die is called. decl_die seems to see the "OK" and decides to continue the request. Let me know if you need further info.
I forgot: decl_die continues, but the fixups in request.c in ap_process_request_internal can't be called anymore. The url for the proxy request isn't completed with the request parameters -> proxy request goes out without them.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.