15 января 2008 в 3:02
1. проапгрейдиться до lighttpd версии не менее 1.4.13 скомпилированным с поддержкой lua и lua версии не менее 5.1
2. в lighttpd.conf в разделе server.modules указать "mod_magnet",
3. ниже, в основном конфиге, либо в конфиге виртуального сервера написать строчку:
magnet.attract-physical-path-to = ( server.document-root + "/rewrite.lua" )
обратить внимание на то, чтобы переменная server.document-root уже содержала к этому времени значение каталога, в которомнаходится Drupal
4. в корневом каталоге сайта, там же, где обычно находится .htaccess создать файл rewrite.lua, в который поместить текст следующего содержания:
attr = lighty.stat(lighty.env["physical.path"])
if (not attr) then
lighty.env["physical.path"] = lighty.env["physical.doc-root"] .."index.php"
if(lighty.env["uri.query"]) then
lighty.env["uri.query"]="q="..lighty.env["physical.rel-path"].."&"..lighty.env["uri.query"]
else
lighty.env["uri.query"]="q="..lighty.env["physical.rel-path"]
end
end5. перезапустить lighttpd
Суррогатное решение можно получить и в предыдущих версиях lighttpd, без использования модуля mod_magnet, однако поскольку в этом случае проверка на существование файлов проводиться не будет, возможны различные неприятные сюрпризы.
Полная версия лежит тут.
Комментарии
В чём +/- такого способа преобразования адресов по сравнению со встроенным в lighttpd? А по сравнению с nginx и mod_rewrite в Apache?
Думается, подгрузка интерпретатора lua при КАЖДОМ запросе, создаст дополнительные нехилые тормоза.
Встроенный интерпретатор скриптового языка конечно даёт гибкость (в nginx к примеру прицеплен perl), но в данном случае невозможность разрулить правила преобразований апачевского mod_rewrite скорее выглядит как недостаток lighttpd.
главное и основное преимущество в том, что проверяется фактическое наличие запрашиваемого файла и преобразование clean url выполняется только если это необходимо. Это также может быть полезно, если двигаться дальше и выполнять кэширование средствами lighttpd.
Не думаю, что "подгрузка интерпретатора lua" происходит при каждом запросе, впрочем, изменение нагрузки можно при необходимости определить экспериментально.
невозможность разрулить правила преобразований апачевского mod_rewrite - немного не понял, это в каком случае?
реализовывать апачевский mod_rewrite полностью на mod_magnet вряд ли есть смысл, и гибкость тут особой роли не играет, т.к. тестовый сервер и перегрузить не жалко, а у продакшена все равно всё по-максимуму должно быть жестко в конфигах.
Как я понял из статьи, сделать проверку наличия файлов средствами конфига lighttpd нет возможности - нужно передевать url скрипту, который этим займётся. Я не занимался этой задачей под lighttpd, но под nginx можно сделать проверку наличия директорий/файлов и воспроизвести любые регвыражения из mod_rewrite. Поэтому заключил, что в случае lighttpd это недостаток - модуль вебсервера полагаю исполнит эти задачи быстрей, чем скрипт.
нет, это не совсем так - определить наличие файла с помощью mod_rewrite действительно нельзя, но mod_magnet - это модуль lighttpd, который (как утерждается) выполняется в ядре, файл со скриптом кэшируется и недостаток по сравнению с жестким конфигом только в том, что постоянно проверяется "свежесть" файла.
А чем он лучше nginx с fastcgi?
Да ничем. php там тоже через fastcgi. Просто бывают ситуации, когда приходится работать с тем, что есть.