nginx: /message.php?from=<id1>&to=<id2> -> /user/message/new/<id2>

Question

[Владимир Чернышев]

Портирую одно PHP приложение под RoR. Сначала хотел переписать всё с нуля, но требуют вводить новые фичи как можно скорее. Решил поступить так: ищу php скрипты, касающиеся новой фичи, переписываю их под рельсы (работа с той же БД), внедряю. Рельсы крутятся под nginx+passenger. Стоит задача трансляции адресов из пространства php (*.php?*) в RoR REST. Вижу два варианта:
— внутренний rewrite с php на ror для уже портированных скриптов
— определять location с passenger _enabled on для уже портированных скриптов и переписывать запрос уже в ruby приложении (middleware например).

Как бы вы поступили?

Answer 1

[VBart]

"— внутренний rewrite с php на ror для уже портированных скриптов"
Ибо незачем костыли пихать в код. А на уровне настройки nginx, вполне терпимо. Только не понятно, почему внутренний rewrite, а не нормальный полноценный 301 редирект?

Comments

[Владимир Чернышев]

Кто его знает этот ruby/rails way, боюсь свои привычки c PHP переносить :) Слышал, что бывает вообще без сервера отдельного обходятся. Всё на ruby — и сокеты слушают, и статику отдают, и…

Полноценный редирект — думал, но конфиг, по-моему очень сложным будет. Универсальный location для ror быстро написать не получится, по-моему, а значит каждая новая реализация будет описываться двумя локэйшенами: сначала редирект для старого урла, потом passenger_enable on для нового.

[whitequark]

Сервер Webrick, который входит в стандартную библиотеку Ruby, может использоваться Rails как основной (в т.ч. через него идет отдача статики), но это очень, очень, очень медленно — я даже не говорю о том, что идет в один поток — поэтому используется максимум на девелоперской машине.

[VBart]

Да в чем проблема то? =)

Ставим первым location-ом что-то такое:

location ~ ^/message.php?from=(.*)&to=(.*)$ {
    rewrite ^ /user/message/new/$2 permanent; 
}

И все, далее локэйшн на .php, аля:

location ~ \.php$ {
    ... 
}

И далее, location на статические файлы, в который отправится все остальное, аля:

location ~ ^/ {
   try_files  $uri @passanger;
}

Он проверит наличие файла на сервере, если есть — отдаст его. Если нет, передаст запрос в location с passanger on.

location @passanger {
   passenger _enabled  on;
}

Желательно конечно, location с try_files заменить на что-то более специфическое, чтобы не проверять без надобности каждый url явно не похожий на файл, а лучше все статические файлы сложить в отдельную папку, а еще лучше даже на отдельный домен.

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

[Владимир Чернышев]

Спасибо! Как-то про try_files и именованный локэйшен в голову не пришло, хотя буквально на днях делал их для блога :)