index internal redirect

Gena Makhomed gmm на csdoc.com
Вс Июн 19 18:29:42 MSD 2011


On 16.06.2011 22:37, Valery Kholodkov wrote:

>>>> Сейчас при нахождении индексного файла делается внутрений редирект.
>>>> Это позволяет работать конфигурациям типа
>>>>
>>>> location / {
>>>> index index.php;
>>>> }
>>>>
>>>> location ~ \.php$ {
>>>> ...
>>>> }
>>>>
>>>> Но иногда нужно, чтобы обработка проиходила без редиректа,

[...]

>> Для try_files хотелось бы придумать ещё два модификатора - делать
>> внутренний редирект при нахождении файла (как сейчас делается для index)
>> и проверка абсолютного пути (а не относительно root/alias).
>> Например, абсолютный путь - два начальных слэша:
>>
>> try_files //path/to/maintenance.html $uri $uri/ @php;
>
> Я запутался: try_files вроде бы напрямую c index никак не связан? Не
> является ли неприменяемость внутреннего редиректа свойством индексного
> файла (а точнее его URI)? Соответстенно, не должны ли модификаторы
> применятся к параметрам директивы index?

возможно действительно будет более полезным модифицировать параметры
директивы index и только в тех случаях, когда это "иногда нужно" - через 
модификатор параметра явно выставлять запрет на "ресолвинг"
индексного файла через внутренний редирект.

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

возможно такой вариант:

index sticky::index.html index.php;

index explicit::index.html index.php;

index strict::index.html index.php;

или какой-то другой синоним слов sticky, explicit, strict, и т.п.

в этом примере - обработка индексного файла index.html
происходит без внутреннего редиректа, а индекского файла
index.php - через внутренний редирект и backend-сервер.

=======================================================================

если же на самом деле надо запретить не внутренний редирект,
а только явный запрос со стороны клиентов к индексному файлу:

http://example.com/index.php
http://example.com/index.html

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

=================================================

index hidden::index.php hidden::index.html /default.html;

или:

index hidden::index.html index.php;

в этом фрагменте конфига index.php нельзя скрывать,
потому что весь сайт работает через этот index.php:
http://example.com/index.php?module=blog&article=43

=================================================

и если кто-то снаружи обращается к скрытому индексному файлу,
то nginx ему будет отдавать 404 код, как и в случае конфига:

=================================================

location = / {
     index  index.html index.php;
}

location = /index.html {
     internal;
}

location = /index.php {
     internal;
}

=================================================

причем, feature "скрытый индексный файл" по моим ощущениям
нужна будет в большинстве случаев, и только для экзотических
вариантов http://example.com/index.php?module=blog&article=43
индексный файл index.php нельзя делать скрытым от клиентов.

возможно имеет смысл к директиве index,
в которой по умолчанию индексные файлы открыты,
и если какой-то индексный файл надо скрыть,
через явное указание модификатора hidden::

добавить еще одну директиву hidden_index,
в которой по умолчанию все индексные файлы будут
скрыты, а те, которые надо сделать видимыми клиентам,
необходимо явно задавать с помощью модификатора visible::

это по аналогии с ключевыми словами class и struct
С++, где в struct по умолчанию все члены public,
а в class - все члены по умолчанию private.

то, что более короткая директива index будет иметь
все файлы открытыми, - это правильно, потому что
очень много сайтов на php не смогут нормально работать
если по умолчанию index.php будет скрытым индесным файлом.

очевидный вариант - просто добавить директиву
hidden_index on; которая будет переключать
дефолтовое поведение директивы index - это не самый
лучший вариант, потому что читая фрагмент конфига
нельзя будет понять каким образом работает та или
иная директива index - у нее по умолчанию все файлы
скрыты, или по умолчанию индексные файлы будут открыты.
и чтобы ответить на этот вопрос надо будет просматривать
весь конфиг, начиная с уровня http, дальше server,
и так по всем вложенным location`ам до текущего уровня.

=================================================

аналогично и для модификаторов sticky|explicit|strict
если действительно надо запретить внутренний редирект
- лучше будет сделать отдельную директиву

sticky_index | explicit_index | strict_index

чтобы это поведение было независимыми от наследуемого
из контекста http|server|location поведения для index,
как в случае добавления директивы index_stays  on|off;

иначе, для получения независимого от контекста поведения
директивы index всегда придется явно указывать в конфиге

index_stays  on;
index index.html index.php;

или

index_stays  off;
index index.html index.php;

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

-- 
Best regards,
  Gena




Подробная информация о списке рассылки nginx-ru