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