Re: index internal redirect

[Gena Makhomed <gmm@xxxxxxxxx>]

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 mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru