With a WebDAV client when I use ACL method mod_proxy_ajp says to me : [Wed Dec 06 10:49:47 2006] [error] ajp_marshal_into_msgb - No such method ACL [Wed Dec 06 10:49:47 2006] [error] ajp_send_header: ajp_marshal_into_msgb failed [Wed Dec 06 10:49:47 2006] [error] (120010)APR does not understand this error code: proxy: AJP: request failed to 129.20.999.999:9596 (host.domain.fr) Thanks FYI: I correct this with a patch on ajp_header.c : --- ajp_header.c.ori 2006-12-06 10:54:59.000000000 +0100 +++ ajp_header.c 2006-12-06 11:14:04.000000000 +0100 @@ -159,7 +159,7 @@ SC_M_MKACTIVITY, SC_M_BASELINE_CONTROL, SC_M_MERGE, - 0 /* M_INVALID */ + SC_M_ACL }; static int sc_for_req_method_by_id(int method_id)
This is still a problem in apache 2.2.8 ! Also missing is webdav SEARCH so basic webdav is broken. best regards Eirikur Hrafnsson Chief Software Engineer Idega Software
We found out why SEARCH method does not work and know how to fix it for now. The problem is that M_INVALID that is used to limit which methods are allowed is defined in httpd.h and has the value 26, SEARCH HTTP METHOD gives the value 28 into the method sc_for_req_method_by_id(..) so it won't work. Comparing method_id to positions in an array is at best dubious coding. mod_jk uses some other way to do this and mod_dav obviously since they do work. The fix: Edit ajp_header.c under modules/proxy line 161 in Apache 2.2.8 find: SC_M_MKACTIVITY, SC_M_BASELINE_CONTROL, SC_M_MERGE, 0 /* M_INVALID */ remove that last 0 /* M_INVALID */ line and add instead: SC_M_ACL, 0, SC_M_SEARCH /* needs to be the 28 in the array...*/ and in the method: static int sc_for_req_method_by_id(request_rec *r) change: if (method_id < 0 || method_id > M_INVALID) { to: if (method_id < 0 || method_id > 28) { Where 28 is the size of the methods array we just added to in the beginning. Then compile apache again using for example: > ./configure --prefix=/usr/local/apache2 --enable-mods-shared="all proxy proxy-ajp proxy-balancer filter deflate expires ssl rewrite mime-magic mem-cache info disk-cache dav dav-fs dav-lock" --with-mpm=worker > make > make install Cheers Eirikur S. Hrafnsson and Pall Helgason Idega Software http://www.idega.com
Created attachment 23567 [details] patch against 2.2.11 I think this is still a problem in apache 2.2.11. This patch assigns a id to ACL method. thanks.
6 years passed, but this bug is still relevant, even with 2.2.22. It forces us to use mod_jk to access apache jackrabbit based webDAV, due invalid ACL and SEARCH method handling. Gregory
Same thing here ! bug is still present. We now use mod_proxy_http
The patches in this PR are unfortunately not correct: SEARCH is registered using ap_method_register() by mod_dav. This means the actual number assigned to SEARCH depends on the module loading order. Adding SEARCH and ACL to httpd itself is a good idea, but in stable releases like 2.2.x and 2.4.x, the M_INVALID number must not change.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.