Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: try_files не редиректит сраз у на последний аргумент?
- To: nginx-ru@xxxxxxxxx
- Subject: Re: try_files не редиректит сраз у на последний аргумент?
- From: cronfy <cronfy@xxxxxxxxx>
- Date: Tue, 19 Oct 2010 23:06:14 +0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=gLUNc1EsnikGHJ07KPCpsDe4c8c2iqmP8GOEuPfiPWE=; b=jgqfyFop582k3Jy5zmDVcDt40fCZAgMhO6j5sLEjiDuhxwGmKh7YxhCF6pfLceCl1V Al77T8A7dmxSsPKyjIdrKm1XlWuhRP1L5qkM5P8s21BzRz/W5FGxPjbCNOll+fNJPvD2 LMgzNlL6enJfikqM1JQkLYAPPG0isURXAeI84=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=akcVvAM5252qc9IFZGTecvVK6r6pwuIN310LxXkte0o1V54w/EdOqA1BMUcCLDQ024 CaeyfXEH7mIeG+Qcz8ZJFY4HU8cHL7QW55tSu+d67C7jimlQKeLspoMaJ64MgiIdCQjI 5qsesnF1bfoAVusQ1C4nPkKqoYFv3vN0bSg+4=
- In-reply-to: <20101019155120.GZ44164@xxxxxxxxxx>
- References: <AANLkTi=GX=wRGnXyVAWL0sOPONkvFeq1keZiTv7mx5Bd@xxxxxxxxxxxxxx> <20101019155120.GZ44164@xxxxxxxxxx>
>> Не получается осознать алгоритм работы try_files. Такое впечатление,
>> что после того, как он *не нашел* указанные файлы, он продолжает
>> обрабатывать директивы из текущего location, а не делает внутренний
>> редирект. Имеем такой конфиг:
>>
>> location / {
>> try_files $uri @backend;
>> # return 403;
>> }
>>
>> location @backend {
>> proxy_set_header Host $host;
>> proxy_pass http://127.0.0.1:8091$request_uri;
>> }
>>
>> Если return закомментирован, то все работает как описано в
>> документации. Но если его раскомментировать, то и на существующие, и
>> на несуществующие файлы отдается Forbidden.
>>
>> nginx version: nginx/0.8.50
>>
>> Что я не так понял?
>
> Директива "return" работает в фазе rewrite, это раньше чем фаза
> try_files. Поэтому если написано "return 403" - до try_files дело
> просто не дойдёт.
Понятно, спасибо. Вопрос вот с чем связан - в перловом обработчике
есть проверка существования файла. Если файл не в кэше, проверка
занимает некоторое время, а воркер в это время блокируется на перле. Я
хотел с помощью try_files "прогреть" кэш ОС, в надежде, что воркер
целиком блокироваться не будет. А как на самом деле - будет также
блокироваться на ФС или обработка параллельных запросов во время
try_files будет идти?
--
// cronfy
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|
