On 21.10.2013 21:37, Maxim Dounin wrote:

>>>> Ошибки работы try_files в location с alias ведь можно исправить?
>>
>>> С тем же успехом можно исправить if. О чём и разговор: подход
>>> "давайте вместо того, чтобы исправлять старое, сделаем новое"
>>> приводит к увеличению проблем.
>>
>> следуя такой логике - любая новая feature приводит к увеличению проблем.
>> например, добавили ngx_http_spdy_module - и появились НОВЫЕ проблемы.
>
> Именно так. И поэтому подход "давайте вместо того, чтобы
> исправлять старое, сделаем новое" - не работает.

откуда взялось это жесткое противопоставление двух процессов -
"давайте ВМЕСТО ТОГО, чтобы исправлять старое, сделаем новое"?

в файле http://nginx.org/en/CHANGES почти в каждом выпуске
есть и Bugfix: и Feature: записи - одно другому не мешает.

если исправлять старое методом "disable non-rewrite directives
inside if completely" - это тоже приведет к увеличению проблем.

это можно делать только в том случае если такая feature будет
в состоянии deprecated долгое время и при наличии альтернатив.

а чтобы эти альтернативы были - их надо сначала добавить в nginx,
"сделать новое" и только потом уже можно "disable ... completely"

> Извините, я устал разжёвывать раз за разом одно и то же, поэтому
> воздержусь от продолжения данной дискуссии.

On 16.10.2013 20:33, Maxim Dounin wrote:

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

On 17.10.2013 2:18, Maxim Dounin wrote:

> Речь, впрочем, не об этом. Речь о том, что try_files, который
> делался как попытка "решить" проблемы if'а, вытеснив его из
> конфигов, ни разу его не вытеснил. Наоборот, к существовавшим
> ранее проблемам - добавились новые, в том числе - связанные с
> работой try_files со всё тем же if'ом.

On 17.10.2013 17:09, Maxim Dounin wrote:

> Повторяю: добавление try_files не решило проблем с if'ом. В
> результате как раз с проблемами if'а - ничего не было сделано, а
> вместо этого усилия были потрачены на try_files и борьбу с его
> проблемами. Если бы вместо добавления try_files соответствующие
> усилия были потрачены именно на _решение_ проблем - было бы лучше.
>
> И это общая проблема всех подобных попыток "уменьшить количество
> случаев" вместо реального решения проблемы. Решать проблему всё
> равно рано или поздно придётся, и откладывание этого решения -
> лишь ухудшает ситуацию.

On 18.10.2013 16:50, Maxim Dounin wrote:

> Отдельно печалит, что в результате конфигурации с error_page 404
> @fallback - практически исчезли, хотя аналог на try_files -
> гарантированно хуже.

"ни разу его не вытеснил" и вместе с тем "практически исчезли"

вместо того, чтобы писать в конфиге:

error_page 456 = @fallback;
if (!-f $request_filename) {
return 456;
}

можно написать гораздо проще:

try_files $uri @fallback;

поэтому совсем не удивительно, что конфигурации с "error_page"
практически исчезли, и try_files вытеснил здесь if из конфигов

кроме того, что вместо 4-х строчек конфига надо писать только одну,
есть и дополнительный плюс - try_files корректно работает с access.

или "ни разу его не вытеснил" - это про конфигурации

if (!-f $request_filename) {
fastcgi_pass ...;
}

?

на такие конфигурации nginx -t говорит что "test is successful"
и не ругается, что такая фича deprecated, потому и не вытеснил.

а не ругается наверное потому, что пока что не исправлены
ошибки в работе try_files внутри location`ов с alias`ами.

самый простой путь решения проблем с if:

1. добиться безглючной работы директивы try_files во всех случаях
2. сделать warning о deprecated non-rewrite directives inside if
3. в next major версии disable non-rewrite directives inside if

самый сложный путь решения проблем с if:

устранить все глюки в работе директивы if со всеми директивами nginx
и со всеми возможными их комбинациями: несколько if в location и т.п.

какие-либо другие варианты "решения проблем с if" существуют?

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru