Sapega, получается, что не доходит до редиректа. Если есть другие условия, то они могут перекрывать его.
RewriteRule ^(.*)-rus\.html$ /$1.html [R=301,L]
Похожий вопрос и решение.
Делают в два прохода. Редиректом убирают слеш, а вторым перенаправляют.
1234567890
vaf76, если нужно без редиректа, то [R=301,L] заменить на [L]
RewriteEngine on #1.вариант http://site.ru/component/k2/item/056-plastik -> http://site.ru/kuhni/056-plastik RewriteRule ^component/k2/item/(.*)$ /kuhni/$1 [R=301,L] #2.вариант http://site.ru/component/k2/item/056-plastik -> http://site.ru/056-plastik RewriteRule ^component/k2/item/(.*)$ /$1 [R=301,L]
Очень странно.
Это бред конечно, но попробуйте добавить модификатор u.
preg_replace('!([^\,]+)$!su', ', '.$index.' \1', $u)
Обращал раньше внимание на ошибки пользователей с агентом AppleWebKit, которые идут через MS сервера: 207.46.0.0 - 207.46.255.255, 157.54.0.0 - 157.60.255.255 и т.п. Переводят в нижний регистр всю строку адреса. Для одного сайта это критично и выдаётся 404.
Предположил, что это специальная программа в браузере наподобие прокси. Все программы имеют настройки и глюки. Да и с самих серверов может что угодно приходить.
Запросов немного было, поэтому глубоко не копал и забил.
В строке $u после последней запятой вставляется текст $index. Цифры тут не фигурируют.
В повторном запросе юзер-агент не AppleWebKit? IP пробивали?
Лучше покажите эти строчки лога, коды ответа, отдаваемый размер, агент.
farenheit, у вас очень простой sql запрос. Смысл его кешировать?
Кешировать стоит "тяжёлые" вложенные запросы с join-нами, group by и т.п.
