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=43562>. 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=43562 Summary: PR 21059 is not needed anymore and has degraded the use of mod_speling; please suprress Product: Apache httpd-2 Version: 2.2.6 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: mod_speling AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Please remove PR 21059 from mod_speling as it has downgraded the behavior of Apache 2.2 and also because bug 21059 was solved by changes elsewhere in the code. The patch I'm submitting effectively deletes PR 21059. Detailed report: Way back in 2003, the following dependency was added to mod_speling:check_speling(), as an attempt to fix bug report # 21059 [1] for Apache 2.0.45. This patch was apparently applied only to the 2.2 tree: [[ /* we default to reject path info (same as core handler) */ if ((r->used_path_info != AP_REQ_ACCEPT_PATH_INFO) && r->path_info && *r->path_info) { return DECLINED; } ]] This patch has had a bad side effect on Apache 2.2: use of mod_speling is now conditioned to the use of AcceptPathInfo; it's not possible anymore to use mod_speling without having AcceptPathInfo turned on. With all due respect, I believe that the correct approach would have rather been to add a directive similar to mod_mime's ModMimeUsePathInfo [2], which is "is used to combine the filename with the path_info URL component to apply mod_mime's directives to the request." This requires a deeper code change than what the patch proposed. This patch has also downgraded the behavior of Apache 2.2; if you were using mod_speling, URIs that returned status 404 under Apache 1.3 are now returning status 200, because you need to enable AcceptPathInfo to be able to use mod_speling. If we look at bug report 21059, I see that it is describing a standard behavior in Apache 1.3: 1. the client passed a path_info in its request http://www.abcdatos.com/programas/traductores/ 2. mod_negotiation (and not mod_speling), converted the URI to: http://www.abcdatos.com/programas/traductores/" The real bug here, according to the report, is that the server returns 404, regardless of the user's enabling of AcceptPathInfo. Up to this moment, mod_speling has not been concerned: there has been no spelling correction. Let's jump back to the future and to Apache 2.2. I made the following tests (detailed results here below): 1. Apache 1.3 with mod_speling 2. Apache 2.2.4; mod_speling with PR 21059 and AcceptPathInfo enabled 3. Apache 2.2.4; mod_speling without PR 21059 removed and AcceptPathInfo disabled 4. Apache 2.2.4; mod_sepling witout PR 21059 and AcceptPathInfo enabled To summarize the results, removing the patch to mod_speling and disabling AcceptPathInfo gives us the same behavior as with Apache 1.3. Moreover, removing the patch and enabling AcceptPathInfo does pass the path info to the resource, thus showing that the behavior described in bug report 21059 was fixed elsewhere in the code and that PR 21059 is not needed. There have been other bug reports about the side-effects and nuisance of binding mod_speling with a global AcceptPathInfo (e.g, # 38635 [3] and mailing list posts)). I would strongly advise to remove this dependency and, when resources are available, add a better integration of AcceptPathInfo processing into mod_speling, such as the one done in mod_mime via ModMimeUsePathInfo. Cheers, -jose [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=21059 [2] http://httpd.apache.org/docs/2.2/mod/mod_mime.html#modmimeusepathinfo [3] http://issues.apache.org/bugzilla/show_bug.cgi?id=38635 --------------- detailed tests We're requesting http://www.w3.org/INSTALL.html, using different versions of the Apache server and different variations on the URI. -------------- 1. Apache 1.3.37 (gives us our "standard" behavior) *** Without '/' after the URI: http://www.w3.org/INSTALL.html --> 200 OK http://www.w3.org/INSTALL --> 200 OK Content-Location: INSTALL.html http://www.w3.org/Install --> 300 Multiple Choices (INSTALL.html) http://www.w3.org/Install.html --> 301 Moved Permanently (INSTALL.html) http://www.w3.org/Install.HTML --> 301 Moved Permanently (INSTALL.html) ** With '/' after the URI: --> Content-Location header is not sent anymore http://www.w3.org/INSTALL/ --> 404 Not Found http://www.w3.org/INSTALL.html/ --> 404 Not Found http://www.w3.org/Install/ --> 300 Multiple Choices (/INSTALL.html/) http://www.w3.org/Install.html/ --> 301 Moved Permanently (INSTALL.html/) --> Conclusion: They will all end returning 404 ** With '/foo' after the URI: http://www.w3.org/INSTALL.html/foo --> 404 Not Found http://www.w3.org/INSTALL/foo --> 404 Not Found --> No redirection http://www.w3.org/Install.html/foo --> 301 Moved Permanently (INSTALL.html/foo) http://www.w3.org/Install/foo --> 300 Multiple Choices (INSTALL.html/foo) --> Conclusion: They will all end returning 404 Summary: Only INSTALL returns valid content in the end; all the other variations, INSTALL/ or INSTALL/foo, return 404. ============== 2. Apache 2.2.4 with AcceptPathInfo enabled; mod_speling contains PR 21059 *** Without '/' after the URI: http://www.w3.org/INSTALL.html --> 200 OK http://www.w3.org/INSTALL --> 200 OK Content-Location: INSTALL.html http://www.w3.org/Install --> 300 Multiple Choices (INSTALL.html) http://www.w3.org/Install.html --> 301 Moved Permanently (INSTALL.html) http://www.w3.org/Install.HTML --> 301 Moved Permanently (INSTALL.html) ** With '/' after the URI: http://www.w3.org/INSTALL/ --> 200 OK http://www.w3.org/INSTALL.html/ --> 200 OK http://www.w3.org/Install/ --> 300 Multiple Choices (/INSTALL.html/) http://www.w3.org/Install.html/ --> 301 Moved Permanently (INSTALL.html/) ** With '/foo' after the URI: http://www.w3.org/INSTALL/foo --> 200 OK http://www.w3.org/INSTALL.html/foo --> 200 OK http://www.w3.org/Install/foo --> 300 Multiple Choices (/INSTALL.html/foo) http://www.w3.org/Install.html/foo --> 301 Moved Permanently (INSTALL.html/foo) Summary: The server always return status code 200 if we want to use mod_speling, because of the biding with AcceptPathInfo on. There's no way to have the same behavior as under Apache 1.3. ======= 3. Apache 2.2.4 with AcceptPathInfo disabled; mod_speling without PR 21059 *** Without '/' after the URI: http://www.w3.org/INSTALL.html --> 200 OK http://www.w3.org/INSTALL --> 200 OK Content-Location: INSTALL.html http://www.w3.org/Install --> 300 Multiple Choices (INSTALL.html) http://www.w3.org/Install.html --> 301 Moved Permanently (INSTALL.html) http://www.w3.org/Install.HTML --> 301 Moved Permanently (INSTALL.html) ** With '/' after the URI: http://www.w3.org/INSTALL/ --> 404 Not Found http://www.w3.org/INSTALL.html/ --> 404 Not Found http://www.w3.org/Install/ --> 300 Multiple Choices (/INSTALL.html/) http://www.w3.org/Install.html/ --> 301 Moved Permanently (INSTALL.html/) ** With '/foo' after the URI: http://www.w3.org/INSTALL.html/foo --> 404 Not Found http://www.w3.org/INSTALL/foo --> 404 Not Found http://www.w3.org/Install.html/foo --> 301 Moved Permanently (INSTALL.html/foo) http://www.w3.org/Install/foo --> 300 Multiple Choices (INSTALL.html/foo) Conclusion: Removing PR 21059 and disabling AcceptPathInfo gives us the same behavior as under Apache 1.3. mod_speling is not conditioned anymore to the AcceptPathInfo directive. ========== 4. Apache 2.2.4 with AcceptPathInfo enabled; mod_speling without PR 21059 *** Without '/' after the URI: http://www.w3.org/INSTALL.html --> 200 OK http://www.w3.org/INSTALL --> 200 OK Content-Location: INSTALL.html http://www.w3.org/Install --> 300 Multiple Choices (INSTALL.html) http://www.w3.org/Install.html --> 301 Moved Permanently (INSTALL.html) http://www.w3.org/Install.HTML --> 301 Moved Permanently (INSTALL.html) ** With '/' after the URI: http://www.w3.org/INSTALL/ --> 404 Not Found http://www.w3.org/INSTALL.html/ --> 404 Not Found http://www.w3.org/Install/ --> 300 Multiple Choices (/INSTALL.html/) http://www.w3.org/Install.html/ --> 301 Moved Permanently (INSTALL.html/) ** With '/foo' after the URI: http://www.w3.org/INSTALL.html/foo --> 200 OK http://www.w3.org/INSTALL/foo --> 200 OK http://www.w3.org/Install.html/foo --> 301 Moved Permanently (INSTALL.html/foo) http://www.w3.org/Install/foo --> 300 Multiple Choices (INSTALL.html/foo) Conclusion: Removing PR 21059 and enabling AcceptPathInfo gives us the same behavior as under Apache 1.3, with the addition of being able to pass on the path info to the resource. This shows effectively that bug #21059 was solved elsewhere in the code and that PR 21059 in mod_speling is not related at all. -- 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]
