https://issues.apache.org/bugzilla/show_bug.cgi?id=47644
josh ribakoff <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #6 from josh ribakoff <[email protected]> 2009-08-05 13:31:27 PDT --- Ok so multi views in the documentation answers my question, that apache will basically randomize what it serves with some convoluted weighting scheme. great. but shouldn't a rewrite rule with an [L] flag take precedence over this ( undesired! ) feature?? I am not sure if that is "by design" or not but it simply does not make sense, so I am just suggesting, if the user asks to rewrite a URL There are people whos SEO is being destroyed by this "feature" http://www.gerd-riesselmann.net/archives/2005/04/beware-of-apaches-multiviews http://www.webmasterworld.com/apache/3595094.htm IT WOULD APPEAR that your users disagree with you. At the very least in my humble opinion the rewrite engine should run before the multi-views so that the [L] flag does what it intends to, I for one feel that this contradicts what is stated in the rewrite engine documentation then "Once a request comes in, and Apache has determined the appropriate server (or virtual server), the rewrite engine starts the URL-to-filename translation," This is incorrect then, it should state that multiviews and god knows what else can mess with the URL first, even if it didn't state specific modules, theres nothing to lead a newb like me to believe the rewrite engine isn't _first_ in the chain "It is in the documentation. But this is the WRONG PLACE to discuss that." So if there are issues with the documentation then APACHE doesn't want to know about it? Really? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- 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]
