https://bz.apache.org/bugzilla/show_bug.cgi?id=70020
--- Comment #4 from Philippe Cloutier <[email protected]> --- Greetings Rich, (In reply to Rich Bowen from comment #1) > Regarding the structural changes (points 2–4) — converting the definition > list to an unordered list, merging the path items, and restructuring the > tables — we're not planning to take on that level of docs restructuring at > this time. The current structure has been stable and widely referenced, and > a large-scale rewrite carries risk of introducing new confusion. Thanks for sharing your plans, but I don't see anything close to a large-scale rewrite in what I suggested. I wonder what you mean by “widely referenced”, but if you refer to links, I do not expect anything I suggested to cause significant disruption on incoming links. Any change should be careful to avoid introducing regressions, and you will hardly find a greater advocate of reliability than myself, but I don't think mod_rewrite should put much focus on “documentation stability”, in particular at this point. Currently, resources are spread in the official documentation, in the wiki, on Stack Exchange (mostly Stack Overflow and Server Fault) and elsewhere. Just a few: https://stackoverflow.com/questions/20563772/reference-mod-rewrite-url-rewriting-and-pretty-links-explained/31280108#31280108 https://stackoverflow.com/questions/9153262/tips-for-debugging-htaccess-rewrite-rules Stack Overflow even has its own official introduction to mod_rewrite: https://stackoverflow.com/tags/mod-rewrite/info Some even dig old official documentation: https://stackoverflow.com/a/15599770/5405434 There is even a .htaccess tester (which I wish was managed by Apache): https://htaccess.madewithlove.com/ Some of the answers and comments do not praise official documentation: https://stackoverflow.com/questions/21347768/what-does-rewritebase-do-and-how-to-use-it/56828604#comment112444430_21348047 https://serverfault.com/questions/214512/redirect-change-urls-or-redirect-http-to-https-in-apache-everything-you-ever The page pointed by the previous link matches a lot better what I would call “a large-scale rewrite” of rewriting documentation.🫤 I think users would be much better served by clear rewritten official documentation than by unofficial and unreliable rewritten documentation. And I would be very surprised if whatever stability concerns are considered warranted maintaining semantic invalidity. (In reply to Rich Bowen from comment #3) > Fixed in r1933815 (trunk) and r1933816 (2.4). > > Added a note to the RewriteRule documentation clarifying how substitution > paths are interpreted across all combinations of context (server/vhost vs. > per-directory) and whether the path begins with a slash. Thank you very much again I agree that all combinations are now specified, but the result is unfortunately incoherent for relative substitutions. For example, in server/vhost context, the box indicates the substitution is relative to the current request URI. But according to the “definition”, the path is relative to the “DocumentRoot”. By the way, while most will understand “on disk”, it is getting dated. “on secondary storage” would be much more accurate. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
