lucy24 - 7:17 am on Jul 27, 2013 (gmt 0)
it's causing the last character of a valid url to get truncated. So example.com/page is 301 redirecting to example.com/pag
Oh, ###. That means it's backtracking when it doesn't have to. (Where "doesn't have to" = Look, mod_rewrite, you don't have to execute this rule, you can just say it doesn't fit.)
I would say simply \W in place of [^a-zA-Z\d]. Except, 1, I'm not sure all servers recognize the form, and 2, I kinda think you don't want _ as the last character in an extension. (Can it occur? You can definitely have numerals along with letters.)
If it's example.com/page.html, then adding l? would be adding a second l that's an optional l. So you'd be left with example.com/page.html or example.com/page.htmll. Neither is a valid file.
Ah, interesting. I wasn't sure if it would work at all. Sounds like it would have been the right approach if your filenames had the opposite configuration: Everything ends in .html but some people are asking for .htm
:: detour to test site's htaccess ::
Oh, that's why it works for me. Completely different pattern.
RewriteRule ^(([^./]+/)*[^./]+\.(html|php))/ http://www.example.com/$1 [R=301,L]
First, I limited the rule to specific extensions. Second, I named a specific character to come after the extension-- though I could have said .+ at this point. For some reason, only my test site has ever been plagued with bogus path info. Others may have tried-- but only from IPs that were already blocked anyway.
I generally constrain RewriteRules to requests for pages: patterns like
This is admittedly easiest to achieve in access-control rules where you don't need to capture things; all you're deciding is whether the guy gets in at all. It's very rare for a malign robot to walk in off the street and start demanding image files, so all of those just whizz on past the server. (On my main site they're actually inside a FilesMatch envelope-- images inside, everything else outside-- but officially you are not supposed to do this. Nobody told me.)