Htaccess rewriterule не работает

.htaccess: RewriteRule не работает, используя только значение

Я провел много исследований, чтобы решить эту проблему, но до сих пор не могу понять, почему это не сработает. Первоначально я переписал свои URL, чтобы добавить .html но я хочу изменить это и сделать их простыми без суффиксов.

Вот пример оригинальной ссылки

Я использовал правило ниже, чтобы изменить ссылку выше и добавить суффикс .HTML

RewriteRule ^([^/]*)\.html$ /artist?a=$1 [L]

Я хочу переписать оригинальную ссылку на что-то вроде этого

Я пытался использовать RewriteRule ^([^/]*)$ /artist?a=$1 [L] чтобы добиться этого, но я получаю ужасную ошибку сервера

Внутренняя ошибка сервера Сервер обнаружил внутреннюю ошибку или неверную конфигурацию и не смог выполнить ваш запрос.

Пожалуйста, свяжитесь с администратором сервера webmaster@howwe.biz и сообщите им о времени возникновения ошибки и обо всех действиях, которые вы могли совершить, возможно, вызвавших ошибку.

Дополнительная информация об этой ошибке может быть доступна в журнале ошибок сервера. Кроме того, при попытке использовать ErrorDocument для обработки запроса произошла ошибка 500 Internal Server Error.

индукционный Kenzo в URL это значение. Что странно, если я добавлю имя, которое в этом случае , оно работает. Увидеть ниже:

RewriteRule ^a/([^/]*)$ /artist?a=$1 [L] действует для http://www.howwe.biz/a/bebe-cool но мне нужно вот так http://www.howwe.biz/bebe-cool

Что я делаю не так? Ваша помощь будет высоко ценится.

Извините, если это был д-р.

Решение

Это должно работать:

RewriteRule ^([^/]*)$ /artist?a=$1 [L] не удалось, потому что он переписывает любой запрос к целевому URL безоговорочно, целевой URL совпадает с шаблоном и перезаписывает сам на себя. Ваше правило будет работать при следующих условиях:

Другие решения

Он берет все из-за последнего / до конца и добавляет его к 1 доллару.

Источник

Как отлаживать.htaccess RewriteRule не работает

у меня есть RewriteRule на .htaccess файл, который ничего не делает. Как я могу устранить эту проблему?

• как я могу проверить, если .htaccess файл даже читается и подчиняется Apache? Могу ли я написать Эхо-сообщение «это работает», если я его напишу, где эта строка будет отражена?
• если .htaccess файл не используется, как я могу заставить Apache использовать его?
• если .htaccess используется, но мой RewriteRule все еще не имеет эффекта, что больше могу ли я сделать отладку?

7 ответов:

введите некоторые ненужные значения в ваш .htaccess например, foo bar , sakjnaskljdnas любое ключевое слово, не распознанное htaccess и посетите свой URL. Если он работает, вы должны получить

500 Внутренняя Ошибка Сервера

Внутренняя Ошибка Сервера

сервер обнаружил внутреннюю ошибку или неправильной настройки и не смог выполнить ваш запрос.

я предлагаю вам поставить его вскоре после RewriteEngine on .

так как вы находитесь на вашей машине. Я предполагаю, что у вас есть доступ к Apache .

открыть .conf файл, и искать строку, похожую на:

если он прокомментирован (#), раскомментируйте и перезапустите apache.

для перезаписи журнала

поставить выше 3 строки в свой virtualhost . перезапустите httpd.

RewriteLogLevel 9 использование высокого значения для уровня замедлит ваш Apache сервер резко! Используйте перезапись файла журнала на уровне выше 2 только для отладки! Уровень 9 будет регистрировать почти каждую деталь перезаписи.

обновление

все изменилось в Apache 2.4:

The RewriteLog и RewriteLogLevel директивы были удалены. Эта функция теперь предоставляется путем настройки соответствующего уровень ведения журнала для модуля mod_rewrite с помощью LogLevel. См. также раздел лесозаготовки и mod_rewrite.

для получения дополнительной информации о LogLevel, обратитесь Директива LogLevel

ответ «введите какое-то нежелательное значение» не сделал трюк для меня, мой сайт продолжал загружаться, несмотря на введенный мусор.

Я добавил следующую строку в верхней части .файл htaccess:

это быстро даст вам знать, если .htaccess является то, что подобрали или нет. Если.htaccess используется, файлы в этой папке не будут загружаться вообще.

вообще никаких изменений .htaccess должен иметь видимые эффекты. Если нет эффекта, Проверьте свои файлы конфигурации apache, что-то вроде:

следует заменить на

и вы сможете изменить директивы .htaccess файлы.

возможно, более логичным способом было бы создать файл (например, тест.html), добавьте некоторый контент, а затем попробуйте установить его в качестве индексной страницы:

для большей части .правило htaccess переопределит конфигурацию Apache, где работает на уровне каталога / файла

если у вас есть доступ к каталогу apache bin вы можете использовать,

httpd -M чтобы проверить загруженные модули.

после этого простые директивы, как Options -Indexes или deny from all будет затвердевать, что .htaccess работают правильно.

чтобы проверить правила перезаписи htaccess, просто заполните url-адрес, к которому вы применяете правила, поместите содержимое вашего htaccess в большую область ввода и нажмите кнопку «Тест».

Почему бы не положить немного мусора в вашем .htaccess файл и попробуйте перезагрузить apache. Если apache не запускается, вы знаете его работу. Удалите мусор, а затем перезагрузите apache, если он загружает поздравления, которые вы настроили .правильно реврайт.

Источник

Как отлаживать.откройте файл. htaccess RewriteRule не работает

у меня есть RewriteRule на .htaccess файл, который ничего не делает. Как я могу устранить это?

• как я могу проверить, если .htaccess файл даже читается и подчиняется Apache? Могу ли я написать Эхо-сообщение «это работает», если я его напишу, где эта строка будет отражена?
• если .htaccess файл не используется, как я могу заставить Apache использовать его?
• если .htaccess используется, но мой RewriteRule все еще не оказывает эффекта, что еще могу ли я сделать отладку?

7 ответов

введите некоторые ненужные значения в ваш .htaccess например, foo bar , sakjnaskljdnas любое ключевое слово, не распознанное htaccess и посетите свой URL. Если это работает, вы должны получить

500 Внутренняя Ошибка Сервера

Внутренняя Ошибка Сервера

сервер обнаружил внутреннюю ошибку или неправильной настройки и не смог выполнить ваш запрос.

я предлагаю вам положить его вскоре после RewriteEngine on .

так как вы находитесь на вашей машине. Я полагаю, у вас есть доступ к apache .

открыть .conf file, и найдите строку, похожую на:

если он прокомментирован (#), раскомментируйте и перезапустите apache.

поставить выше 3 строки в свой virtualhost . перезапустите httpd.

RewriteLogLevel 9 использование высокого значения для уровня замедлит ваш Apache сервер драматически! Используйте файл журнала перезаписи на уровне больше 2 только для отладки! Уровень 9 будет регистрировать почти каждую деталь rewritelog.

обновление

в Apache 2.4 все изменилось:

на RewriteLog и RewriteLogLevel директивы были удалены. Эта функциональность теперь обеспечивается путем настройки соответствующего уровень ведения журнала для модуля mod_rewrite с помощью LogLevel. См. также раздел лесозаготовки и mod_rewrite.

подробнее о LogLevel см. Директива LogLevel

таким образом, теперь

ответ «Enter some junk value» не сделал трюк для меня, мой сайт продолжал загружаться, несмотря на введенный мусор.

вместо этого я добавил следующую строку в верхнюю часть .файл htaccess:

это быстро даст вам знать, если .htaccess подбирается или нет. Если.htaccess используется, файлы в этой папке не будут загружаться вообще.

вообще любое изменение .htaccess должен иметь видимые эффекты. Если нет эффекта, проверьте файлы конфигурации apache, что-то вроде:

следует заменить на

и вы сможете изменить директивы .htaccess файлы.

возможно, более логичным методом было бы создать файл (например, test.html), добавьте некоторое содержимое, а затем попробуйте установить его в качестве страницы индекса:

по большей части, the .правило htaccess переопределит конфигурацию Apache, где работает на уровне каталога / файла

если у вас есть доступ к каталогу apache bin, который вы можете использовать,

httpd -M чтобы проверить загруженные модули.

после этого простые директивы, такие как Options -Indexes или deny from all будет затвердевать, что .htaccess работают правильно.

чтобы проверить правила перезаписи htaccess, просто заполните url-адрес, к которому вы применяете правила, поместите содержимое htaccess в большую область ввода и нажмите кнопку «Тест».

Почему бы не положить какой-то мусор в вашем .htaccess файл и попробуйте перезагрузить apache. Если apache не запускается, вы знаете его работу. Удалите мусор, а затем перезагрузите apache, если он загружает поздравления, которые вы настроили .правильно реврайт.

Источник

Htaccess rewriterule не работает

Потратил минут 20, пока нашел, почему не работает модуль apache mod_rewrite в Ubuntu 16.04

проверьте в конфигурационном файле /etc/apache2/apache.conf значение директивы AllowOverride

нужно

Options Indexes FollowSymLinks
AllowOverride All
Require all granted

было

Options Indexes FollowSymLinks
AllowOverride None
Require all granted

Предварительно (или потом) нужно включить модуль mod_rewrite командой:

sudo a2enmod rewrite

Проверить подключенные модули можно командой apachectl -M , должно быть что похожее:

core_module (static)
so_module (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
filter_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
negotiation_module (shared)
php7_module (shared)
rewrite_module (shared)
setenvif_module (shared)
status_module (shared)

И перезапустить apache:

sudo systemctl restart apache2

Теперь можно настроить перенаправление в файле .htaccess :

Источник

Отлаживаем правила RewriteRule, или немного об интимной жизни mod_rewrite

У меня RewriteEngine всегда был довольно стрессовой темой. Только вот недавно я вдруг обнаружил, что все как-то улеглось и стало более или менее понятно. Поскольку я совершенно обычный человек, я уверен, что ситуация ошибки конфигурации веб-сервера «доставала» не одного лишь меня, и я спешу поделиться своим опытом.

Получилось нечто среднее между руководством по использованию модуля mod_rewrite и своеобразным справочником по конфигурированию веб-сервера с помощью файла .htaccess. Попутно хотелось бы заострить внимание на особо сложных или неочевидных моментах.

Предполагается, что читатель использует урл-рерайтинг в своей работе, знает, в общих чертах, что такое RewriteEngine и уже провел несколько часов за его настройкой. Эта статья не совсем для начинающих, но и не для супер-профи, конечно.

Исходные данные для опытов

• Все опыты производятся на локальном хосте.
• Установлен сервер lampp
• Версия Apache: 2.4.9 (сборка для Unix)
• В папке /opt/lampp/htdocs/bbb/_engine лежит опытный сайт на домене engine.bbb.ru. Указанная папка является корневой (DocumentRoot).
• В корневой папке сайта лежит всего одна страница ind.php.
• На сайте есть одна папка /opt/lampp/htdocs/bbb/_engine/local.
• В ней лежит один скриптовый файл ind1.php

Настройка виртуальных хостов

Для того, чтобы было проще работать, отлаживать и не трепать себе нервы там, где можно этого не делать, хорошо бы настроить виртуальные хосты с точки зрения удобства. Рассмотрим простейшие настройки, которые очень сильно облегчат нам жизнь.

Настраиваем логи

Мало у кого на локальном сервере всего один домен. Доменов обычно много. Хорошо бы разделить логи по доменам и по дням, чтобы они не слишком разрастались. Делается это через раздел настроек нашего сервера.

Для лога ошибок на нашем домене добавляем следующие две строчки.

Первая задает имя лога ошибок для виртуального сервера и заставляет начинать новый лог каждые 86400 секунд. Rotatelogs является программой, которая в общем случае входит в комплект веб-сервера Apache и я надеюсь, что у вас она тоже установлена.

Вторая строчка задает формат каждой строчки лога ошибок. Подробности можно прочитать в документации к серверу Apache. Там все довольно понятно. В рамках этой статьи важно просто иметь ввиду, что формат настраивается.

Для лога доступа я у себя включаю только одну строчку. Формат строки «по умолчанию» меня обычно устраивает.

В обоих случаях обратите внимание на пути к программам веб-сервера и к логам. Вы должны установить у себя те пути, которые существуют на вашем компьютере.

Самые общие сведения о том, как все работает

Предположим, мы хотим включить в некоторой папке нашего домена сервис переписывания адресов. Для этого мы располагаем строчку

в файле .htaccess, который будет управлять этой папкой. Кроме этого мы располагаем ниже этой строчки другие директивы и несколько правил для рерайтинга.

Предположим, сервер получает на вход некий урл. RewriteEngine начинает этот урл проверять, используя правила. Делает он это сверху вниз по порядку. Если входной урл НЕ УДОВЛЕТВОРЯЕТ ни одному правилу, то он, что называется «проходит». Так, например, предположим, что у нас есть в корневой папке файл index.php. Если входной ури «/index.php» не удовлетворяет ни одному правилу, то мы увидим в браузере результат работы этого скрипта.

Если мы имеем следующее правило

то, очевидно, это правило для ури «index.php» сработает. В этом случае ури будет переписан на «» и новый ури «/» будет послан на вход серверу. И весь процесс применения правил пойдет заново. Только в том случае, если ури «/» не удовлетворит ни одному нашему правилу, мы увидим то, что хотим. А если удовлетворит, то он будет опять переписан и все повторится заново.

Как работает флаг [L]

Наверное, этот флаг вносит особенно много недопониманий. Наличие флага предотвращает проверку входного ури на следующие за ним правила, если это правило сработало. Только и всего. То есть, если наш ури «index.php» прошел проверку (правило для него сработало), то ввиду наличия флага [L] мы прерываем все последующие проверки, и веб сервер сразу производит рерайтинг «index.php» -> «» и получает на вход ури «/» ([INTERNAL REDIRECT] ), и все повторяется с начала, с первого правила. А если этого флага нет, то рерайтинг все равно происходит и проверка продолжается со следующего правила. Но ури будет уже измененный, а именно «/».

Понимание этого процесса сразу предотвращает много циклических редиректов.

Но позвольте, не значит ли написанное выше, что если не использовать флаг [L], мы сэкономим время и страница откроется быстрее? Мы натыкаемся на флаг [L] и должны пройти заново по всем правилам без исключения, а если не ставить флаг [L], то мы сделаем рерайтинг на сработавшем правиле, пройдем до конца всех правил и на этом закончим?

Я проверил. Это не срабатывает. В случае отсутствия флагов [L], модуль, как и предполагается, заменяет ури на сработавшем правиле, идет по всем оставшимся правилам до конца, потом производит [INTERNAL REDIRECT] и все равно проходит с этим ури все правила еще раз. То есть подтверждается то, о чем мы писали выше. Это правило, похоже, не имеет исключений.

Вывод: всегда, когда срабатывает правило RewriteRule, происходит [INTERNAL REDIRECT] и повторное применение всех правил. Этот второй проход начинается либо сразу после применения правила с флагом [L], или после того, как кончатся все правила, если работаем без флагов [L]. Ситуация «прохода» урла, a она называется «pass through» может произойти только в том случае, если ни одно правило не было применено. Флаг [L] действительно может уменьшить время обработки ури и его следует использовать везде, где возможно.

Что есть RewriteBase?

Эта инструкция, на мой взгляд, просто рекордсмен по непонятности! Я бы дал ей за это приз! Ввиду этого у меня есть две истории про этого зверя — короткая и длинная. Короткая история для тех, кто не хочет на эту инструкцию заморачиваться. Длинная для интересующихся.

Короткая история

Если вы занимаетесь относительно простым урл-рерайтингом с помощью файлов .htaccess, то рекомендую всегда поступать следующим образом.

• Не использовать описываемую директиву вообще.
• Во всех правилах рерайтинга целевой урл всегда начинать со слэша (указание на то, что ури указывается относительно корня сайта)

Длинная история

При рерайтинге будут происходить следующие процессы:

Имеем:

• Document Root: /opt/lampp/htdocs/bbb/_engine
• Файл .htaccess лежит там же, в Document Root

Мы запрашиваем урл engine.bbb.ru/ind.php

• Сервис рерайтинга приведет путь запрашиваемого файла к его пути в файловой системе, а именно opt/lampp/htdocs/bbb/_engine/ind.php
• Удалит из него префикс opt/lampp/htdocs/bbb/_engine/ (совпадает с путем к папке, в которой лежит .htaccess)
• Будет применять правила рерайтинга, используя строку «ind.php»

Если в папке /opt/lampp/htdocs/bbb/_engine/local нет файла .htaccess или есть, но в нем не включен RewriteEngine

• Мы запрашиваем урл engine.bbb.ru/local/ind1.php
• Сервис рерайтинга приведет путь запрашиваемого файла к его пути в файловой системе, а именно opt/lampp/htdocs/bbb/_engine/local/ind1.php
• Удалит из него префикс opt/lampp/htdocs/bbb/_engine/
• Будет применять правила рерайтинга, используя строку «local/ind.php»

Если в папке /opt/lampp/htdocs/bbb/_engine/local есть файл .htaccess и в нем включен RewriteEngine

• Мы запрашиваем урл engine.bbb.ru/local/ind1.php
• Сервис рерайтинга приведет путь запрашиваемого файла к его пути в файловой системе, а именно opt/lampp/htdocs/bbb/_engine/local/ind1.php
• Удалит из него префикс opt/lampp/htdocs/bbb/_engine/local/ (это путь к папке, где лежит файл .htaccess директории /local)
• Будет применять правила рерайтинга, используя строку «ind1.php»

Внимание! Такой алгоритм будет выполняться всегда. Этот алгоритм выражает специфику термина «per-dir«, то есть «по-директорного» подхода, заложенного в сервере Apache. Значение директивы RewriteBase никак на него (на алгоритм) не влияет.

На что же влияет директива RewriteBase?

Нужно очень хорошо помнить, что в директиве RewriteBase указывается URL! Нельзя указать там «local/» Будет ошибка! Можно только «/local«.

Пусть в нашем /opt/lampp/htdocs/bbb/_engine/local/.htaccess мы указали

Мы запрашиваем урл engine.bbb.ru/local/

Сработает! И будет осуществлен переход на ури /local/ind1.php

тоже сработает, но переход будет осуществлен на ури /ind1.php. Файл не найден! Такого ури (относительно корня сайта) у нас нет!

Вывод 1: URL, который мы указываем в RewriteBase добавляется в качестве префикса к целевому ури в том случае, если он является относительным, то есть в начале нет слэша.

Вывод 2: Если мы никогда не используем относительные целевые ури в правилах, то и директива RewriteBase нам не нужна!

Вывод 3: Если мы используем «RewriteBase /», то при срабатывании правила

Будет попытка прейти на ури /ind1.php. Мы просто используем «/» в качестве префикса.

Мы имеем следующие правила RewriteEngine в корневом .htaccess:

Если RewriteBase является урлом, то давайте установим

Нет. Не проходит. Ошибка «RewriteBase: argument is not a valid URL«. Странно, правда? Но мы не сдаемся! Меняем RewriteBase!

В этом случае ошибки нет! Что же у нас происходит с путями? Очень много интересного!
Сервер честно получает путь /opt/lampp/htdocs/bbb/_engine/, удаляет из него префикс /opt/lampp/htdocs/bbb/_engine/ и работает с пустой строкой (»).
Натыкаемся на правило и меняем пустую строку на ‘ind.php’
Честно добавляем префикс «//bbb.ru» и отправляемся на следующий проход. Этот второй проход эквивалентен вызову engine.bbb.ru//bbb.ru/ind.php, что, по большому счету является совсем не тем, что мы хотели (было первоначальное желание скакнуть на другой сайт). Короче, идея себя не оправдала. В итоге у нас возникает ошибка 404, что логично. Кстати, «//» были в процессе рерайтинга заменены сервером на «/«. Трассировка этого примера дана значительно ниже.

Как я получил все эти захватывающие дух сведенья об интимной жизни сервера Apache? Или наконец-то об отладке

Действительно! Как я увидел ошибки, который выдает сервис переименования урлов? Ведь именно это и есть отладка! Есть очень полезная директива, которую я вставил в виртуальные хосты для домена engine.bbb.ru. А именно

После вставки я перезагрузил Apache. И с этого момента в лог ошибок домена, а именно в файл /opt/lampp/logs/engine-bbb-error.2015.08.08.log стали вставляться строки трассировки, относящиеся к модулю rewrite. Строк много. Почему trace4? Может быть можно вставить trace3? Можно. Но тогда нельзя будет отладить RewriteCond, не будет детальной информации что и с каким паттерном мы сравниваем и пропадет информация о некоторых других событиях (не столько важных, сколько интересных).

А что такое «warn«? Буквально наша запись LogLevel означает, что для всех модулей уровень ошибок warn и только для модуля rewrite — trace4

Что мы получаем в результате включения отладки?

Получаем трассировку, или очень-очень подробный лог. Трассировочных строк действительно много. Если я попадаю в сложный затык с правилами, и после какого-то времени мучений у меня ничего не получается, и я принимаю решение включить трассировку, то я в своем .htaccess отключаю все правила, которые не относятся к испытуемому урлу. Ставлю перед ними знак комментария «#». После этого перезагружаю страницу, которая не работает и стараюсь найти нужные строки в логе.

Представляю трассировку рерайтинга со следующими условиями:

Обратите внимание на то, что каждая строка помечена указанием уровня (rewrite:trace_). Видимо, если вы нашли в логе какую-то одну, особо нужную вам строку, и хотите посмотреть только однотипные, то меняете уровень трассировки, перезагружаете Apache и повторяете операцию. Мне лично кажется такой путь не совсем облегчающим задачу. Куда легче, на мой взгляд, сначала скопировать строки в отдельный файл, ориентируясь только по времени операции (по минутам). Потом отделить от них другие нужные строки путем удаления ненужной информации (search-replace). Я сначала даже думал сделать на PHP инструмент для просмотра логов такого рода. Но потом необходимость отпала сама собой (остановлюсь на этом ниже).

Отладка действует именно для того виртуального хоста, для которого указана

Если домен engine.bbb.ru использует внешние стили css, которые берутся с домена bbb.ru, и проблема именно в этом, то не надо включать отладку в пределах виртуального сервера engine.bbb.ru, а надо включать в виртуальном сервере bbb.ru. Тогда все вызовы к домену bbb.ru надо смотреть в логах ошибок (не доступа!) домена bbb.ru. При этом вызовов к трассируемым объектам не будет в логах доступа вообще!

А можно не пользоваться столь стрессовым RewriteEngine вообще?

Можно перейти на использование всего одного скрипта на весь сайт и делать весь рерайтинг в нем. На PHP это сделать легче, да и отлаживать куда проще. Кроме явных преимуществ в вопросах безопасности сайта, мы получаем удобство рерайтинга без нервотрепки. Для того, чтобы перейти на такую схему работы, наш .htaccess должен быть примерно такой:

И в скрипте dispatch.php очень советую не забыть запретить прямой вызов самого dispatch.php.

Если вам этот подход вдруг захочется перенять, то рекомендую скрипт dispatch.php назвать как-нибудь иначе. Я использовал это название только в целях наглядности.

К слову, этот подход внедряется довольно активно. Этому мы должны быть благодарны внедрению ЧПУ (урлов, понятных для человека, хотя лично для меня они очень непонятны). Практически во всех современных движках он уже действует.

Источник