<div dir="ltr">Изначально if'ы задействовались исключительно ради желания отдать красивую 500-ю страничку вместо "forbidden". Потом еще потребовалось фильтровать доступ, основываясь на информации в заголовках (к примеру, анализировать $http_x_forwarded_for вместо $remote_addr).... Поэтому простой allow/deny уже не прокатывал.<br>
А использование if внутри map что, не таит в себе никаких неожиданностей?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2 сентября 2013 г., 12:44 пользователь <span dir="ltr"><<a href="mailto:nginx-ru-request@nginx.org" target="_blank">nginx-ru-request@nginx.org</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Сообщения, предназначенные для списка рассылки nginx-ru, необходимо<br>
отправлять по адресу<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<br>
Для изменения параметров подписки вы можеже использовать веб-страницу<br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>
Для получения информации о том, как пользовать почтовым интерфейсом,<br>
отправьте письмо, в теле или теме которого будет слово 'help', по<br>
адресу:<br>
<a href="mailto:nginx-ru-request@nginx.org">nginx-ru-request@nginx.org</a><br>
<br>
Адрес человека, ответственного за этот список рассылки:<br>
<a href="mailto:nginx-ru-owner@nginx.org">nginx-ru-owner@nginx.org</a><br>
<br>
При ответе, пожалуйста, измение тему письма так, чтобы она была более<br>
содержательной чем "Re: Содержание дайджеста списка рассылки<br>
nginx-ru..."<br>
<br>Today's Topics:<br>
<br>
1. 502 уступили место 504 (DenisM)<br>
2. Re: nginx-ru Digest, Vol 47, Issue 4 (Alexander Moskalenko)<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "DenisM" <<a href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Mon, 02 Sep 2013 05:33:19 -0400<br>Subject: 502 уступили место 504<br>Привет.<br>
После включения кеша fastcgi ошибки 502 сменились на 504. Это ожидаемое<br>
поведение?<br>
<br>
fastcgi_cache_path /var/cache/nginx<br>
levels=2<br>
keys_zone=NAME:50m<br>
max_size=1024m<br>
inactive=5m;<br>
fastcgi_temp_path /var/cache/nginx/fastcgi_temp;<br>
fastcgi_cache_key<br>
$cookie_uid|$scheme|$request_method|$host|$request_uri";<br>
fastcgi_cache_methods GET HEAD;<br>
map $request_uri $no_cache {<br>
default 1;<br>
~/gsa/index 0;<br>
~/product/ 0;<br>
}<br>
fastcgi_no_cache $no_cache;<br>
fastcgi_cache_bypass $no_cache;<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?21,242452,242452#msg-242452" target="_blank">http://forum.nginx.org/read.php?21,242452,242452#msg-242452</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Alexander Moskalenko <<a href="mailto:alexander.moskalenko@gmail.com">alexander.moskalenko@gmail.com</a>><br>To: nginx-ru <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>><br>
Cc: <br>Date: Mon, 2 Sep 2013 12:44:08 +0300<br>Subject: Re: nginx-ru Digest, Vol 47, Issue 4<br>В данной конфигурации нужно выкинуть все if и сделать map + if.<br>
Либо использовать allow+deny, как это обычно делают.<br>
<br>
2013/9/2 Андрей Середенко <<a href="mailto:andrei.seredenko@gmail.com">andrei.seredenko@gmail.com</a>>:<br>
> В таком случае, если отрабатывает только последний из if'ов - то в данной<br>
> конфигурации:<br>
><br>
> location ~* /test/url/Page.asmx {<br>
> proxy_pass <a href="http://test_upstream" target="_blank">http://test_upstream</a>;<br>
> proxy_redirect off;<br>
> proxy_set_header Host $host;<br>
> proxy_set_header Remote-Addr $remote_addr;<br>
> proxy_set_header X-Real-IP $remote_addr;<br>
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br>
> proxy_set_header X-Public-Url http://$host$request_uri;<br>
> ...<br>
> some other proxy options<br>
> ...<br>
> #<br>
> set $my_ipsrc 0;<br>
> # allow <a href="http://10.10.1.75/32" target="_blank">10.10.1.75/32</a>;<br>
> if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }<br>
> # allow <a href="http://10.20.1.20/32" target="_blank">10.20.1.20/32</a>;<br>
> if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }<br>
> # allow <a href="http://10.20.1.21/32" target="_blank">10.20.1.21/32</a>;<br>
> if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }<br>
> # allow <a href="http://10.100.1.0/24" target="_blank">10.100.1.0/24</a>;<br>
> if ($remote_addr = <a href="http://10.100.1.0/24" target="_blank">10.100.1.0/24</a>) { set $my_ipsrc 1; }<br>
> # allow <a href="http://178.111.122.133/32" target="_blank">178.111.122.133/32</a>;<br>
> if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }<br>
> # deny all;<br>
> if ($my_ipsrc = 0) { return 500; }<br>
> }<br>
><br>
> всем, кроме последнего адреса, должно возвращаться "500" ?<br>
> или лыжи не едут? :)<br>
><br>
><br>
> 2 сентября 2013 г., 4:16 пользователь <<a href="mailto:nginx-ru-request@nginx.org">nginx-ru-request@nginx.org</a>> написал:<br>
>><br>
>> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо<br>
>> отправлять по адресу<br>
>> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>><br>
>> Для изменения параметров подписки вы можеже использовать веб-страницу<br>
>> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
>><br>
>> Для получения информации о том, как пользовать почтовым интерфейсом,<br>
>> отправьте письмо, в теле или теме которого будет слово 'help', по<br>
>> адресу:<br>
>> <a href="mailto:nginx-ru-request@nginx.org">nginx-ru-request@nginx.org</a><br>
>><br>
>> Адрес человека, ответственного за этот список рассылки:<br>
>> <a href="mailto:nginx-ru-owner@nginx.org">nginx-ru-owner@nginx.org</a><br>
>><br>
>> При ответе, пожалуйста, измение тему письма так, чтобы она была более<br>
>> содержательной чем "Re: Содержание дайджеста списка рассылки<br>
>> nginx-ru..."<br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: true 414 status code (Vladimir Getmanshchuk)<br>
>> 2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)<br>
>> 3. Re: If is Evil (Daniel Podolsky)<br>
>> 4. Re: true 414 status code (Валентин Бартенев)<br>
>> 5. Re: true 414 status code (Валентин Бартенев)<br>
>> 6. Re: If is Evil (Maxim Dounin)<br>
>> 7. Re: If is Evil (Васильев Zmey! Олег)<br>
>> 8. Re: Неправильные (огромные) значения $request time для<br>
>> FastCGI-запросов (Maxim Dounin)<br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: Vladimir Getmanshchuk <<a href="mailto:vladget@gmail.com">vladget@gmail.com</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Sun, 1 Sep 2013 23:33:57 +0300<br>
>> Subject: Re: true 414 status code<br>
>> Амм... Спасибо за скорость и лаконичность.<br>
>><br>
>> Судя по <a href="http://www.w3.org/Protocols/HTTP/HTRESP.html" target="_blank">http://www.w3.org/Protocols/HTTP/HTRESP.html</a>, в HTTP/0.9 тоже есть<br>
>> status codes, или я что то недопонимаю?<br>
>> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"<br>
>><br>
>><br>
>><br>
>><br>
>> 2013/8/31 Валентин Бартенев <<a href="mailto:ne@vbart.ru">ne@vbart.ru</a>><br>
>>><br>
>>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:<br>
>>> > Здравствуйте!<br>
>>> ><br>
>>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414<br>
>>> > status code, на запросы, размер которых, превышает large_client_header_<br>
>>> > buffers?<br>
>>> ><br>
>>> > Постоянно получаю 200 http status code и нижеприведенное в body:<br>
>>> ><br>
>>> > <html><br>
>>> > <head><title>414 Request-URI Too Large</title></head><br>
>>> > <body bgcolor="white"><br>
>>> > <center><h1>414 Request-URI Too Large</h1></center><br>
>>> > <hr><center>nginx/1.2.9</center><br>
>>> > </body><br>
>>> > </html><br>
>>><br>
>>> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.<br>
>>><br>
>>> --<br>
>>> Валентин Бартенев<br>
>>> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>>> _______________________________________________<br>
>>> nginx-ru mailing list<br>
>>> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>>> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Yours sincerely,<br>
>> Vladimir Getmanshchuk<br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: "locojohn" <<a href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Sun, 01 Sep 2013 16:44:45 -0400<br>
>> Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)<br>
>> Oleksandr V. Typlyns'kyi Wrote:<br>
>><br>
>> > Как видно из кода стороннего модуля(а туда тоже следовало бы<br>
>> > посмотреть),<br>
>> > там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог<br>
>> > ошибок.<br>
>> > И они явно намекают на content type который теперь<br>
>> > application/javascript.<br>
>> > Добавление его в concat_types должно помочь.<br>
>><br>
>> Спасибо за отличный хинт! Добавление "application/javascript" в<br>
>> concat_types не помогло, пришлось подпатчить исходный модуль concat:<br>
>><br>
>> --- ngx_http_concat_module.c<br>
>> +++ ngx_http_concat_module.c<br>
>> @@ -30,7 +30,7 @@<br>
>><br>
>><br>
>> static ngx_str_t ngx_http_concat_default_types[] = {<br>
>> - ngx_string("application/x-javascript"),<br>
>> + ngx_string("application/javascript"),<br>
>> ngx_string("text/css"),<br>
>> ngx_null_string<br>
>> };<br>
>><br>
>> Ещё раз - спасибо!<br>
>><br>
>> Posted at Nginx Forum:<br>
>> <a href="http://forum.nginx.org/read.php?21,242399,242424#msg-242424" target="_blank">http://forum.nginx.org/read.php?21,242399,242424#msg-242424</a><br>
>><br>
>><br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: Daniel Podolsky <<a href="mailto:onokonem@gmail.com">onokonem@gmail.com</a>><br>
>> To: nginx-ru <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>><br>
>> Cc:<br>
>> Date: Mon, 2 Sep 2013 00:47:34 +0400<br>
>> Subject: Re: If is Evil<br>
>> > да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить<br>
>> > постулат "скажем if в location - НЕТ"<br>
>> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый<br>
>> location, и что туда наследуется, а что нет, и какая там в результате<br>
>> будет конфигурациия - ни за что не прописаешь, как говорили в школе.<br>
>><br>
>> Поэтому мы пользуемся if, но только одним образом - делаем на нем<br>
>> переадресацию в именованный локейшн.<br>
>><br>
>> Отдельно, конечно, смешно то, что это единственный разумный способ<br>
>> пользоваться if, но директивы переадресации как не было, так и нет, и<br>
>> приходится писать что-то вроде if (condition) { error_page 418 =<br>
>> @location; return 418; }<br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: "Валентин Бартенев" <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Mon, 2 Sep 2013 03:02:45 +0400<br>
>> Subject: Re: true 414 status code<br>
>> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:<br>
>> > Амм... Спасибо за скорость и лаконичность.<br>
>> ><br>
>> > Судя по <a href="http://www.w3.org/Protocols/HTTP/HTRESP.html" target="_blank">http://www.w3.org/Protocols/HTTP/HTRESP.html</a>, в HTTP/0.9 тоже<br>
>> > есть<br>
>> > status codes, или я что то недопонимаю?<br>
>><br>
>> Вы ссылаетесь на спецификацию HTTP/1.0. В HTTP/0.9 у ответа не было<br>
>> заголовка:<br>
>> <a href="http://www.w3.org/Protocols/HTTP/AsImplemented.html" target="_blank">http://www.w3.org/Protocols/HTTP/AsImplemented.html</a><br>
>> <a href="http://www.w3.org/DesignIssues/HTTP0.9Summary.html" target="_blank">http://www.w3.org/DesignIssues/HTTP0.9Summary.html</a><br>
>><br>
>><br>
>> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"<br>
>><br>
>> Сам дописывает видимо. Смотрите более простыми средствами, типа netcat'а<br>
>> или<br>
>> telnet'а.<br>
>><br>
>> --<br>
>> Валентин Бартенев<br>
>> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: "Валентин Бартенев" <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Mon, 2 Sep 2013 03:08:04 +0400<br>
>> Subject: Re: true 414 status code<br>
>> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:<br>
>> > On 31.08.2013 23:57, Валентин Бартенев wrote:<br>
>> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,<br>
>> > >> 414<br>
>> > >> status code, на запросы, размер которых, превышает<br>
>> > >> large_client_header_<br>
>> > >> buffers?<br>
>> > >><br>
>> > >> Постоянно получаю 200 http status code и нижеприведенное в body:<br>
>> > >><br>
>> > >> <html><br>
>> > >> <head><title>414 Request-URI Too Large</title></head><br>
>> > >> <body bgcolor="white"><br>
>> > >> <center><h1>414 Request-URI Too Large</h1></center><br>
>> > >> <hr><center>nginx/1.2.9</center><br>
>> > >> </body><br>
>> > >> </html><br>
>> > ><br>
>> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.<br>
>> ><br>
>> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?<br>
>> > тем более, что запрос в 99.9999999% был версии 1.0 или 1.1<br>
>> ><br>
>> > даже если "Request-URI Too Large" - версию протокола<br>
>> > запроса можно узнать из строки запроса, при желании.<br>
>><br>
>> Нельзя. В наихудшим случае (а он обязательно наступит)<br>
>> строка запроса будет бесконечна.<br>
>><br>
>> ><br>
>> > тем более, что протокол версии 0.9 не умеет прислать<br>
>> > клиенту ответ в котором будет указан status code 414<br>
>> ><br>
>> > а парсить тело ответа веб-сервера никто не будет,<br>
>> > различных серверов много и формат ответов разный.<br>
>><br>
>> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже<br>
>> прислал коллегам соответствующий патч на ревью.<br>
>><br>
>> --<br>
>> Валентин Бартенев<br>
>> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Mon, 2 Sep 2013 03:42:31 +0400<br>
>> Subject: Re: If is Evil<br>
>> Hello!<br>
>><br>
>> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:<br>
>><br>
>> > Приветы всем!<br>
>> ><br>
>> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не<br>
>> > рекомендуется, и что использовать его там можно только в купе с return<br>
>> > или<br>
>> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и<br>
>> > почему.<br>
>> ><br>
>> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно<br>
>> > работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а<br>
>> > все<br>
>> > гуглы мира ведут на 3 ссылки:<br>
>> ><br>
>> > <a href="http://wiki.nginx.org/IfIsEvil" target="_blank">http://wiki.nginx.org/IfIsEvil</a><br>
>> > <a href="http://habrahabr.ru/post/74135/" target="_blank">http://habrahabr.ru/post/74135/</a><br>
>> > <a href="http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html" target="_blank">http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html</a><br>
>> ><br>
>> > Но в первой кроме лирики толком ничего не сказано, вторая просто с<br>
>> > первого<br>
>> > же примера плавит мозг, а в последней уже куда по-лучше, примеров<br>
>> > несколько.. но все одно - какой принцип отработки не ясно(<br>
>> ><br>
>> > Ребят, может кто может подробно и последовательно разжевать, КАК это<br>
>> > работает? А то пока получалось обходиться без if'ов, но кто его знает,<br>
>> > что<br>
>> > будет завтра.. не хотелось бы оставить новый след от граблей, старый<br>
>> > только<br>
>> > вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем<br>
>> > просто<br>
>> > запомнить постулат "скажем if в location - НЕТ"<br>
>> ><br>
>> > Буду признателен за любые ответы. Спасибо!<br>
>><br>
>> В первую голову - надо уяснить для себя, что if создаёт вложенный<br>
>> location. И именно в этом location'е в результате будет обработан<br>
>> запрос, если if выполнется. Если таких if'ов много - то запрос<br>
>> будет обработан в последнем if'е, который выполнится. Поэтому<br>
>> конфигурация вида<br>
>><br>
>> location / {<br>
>> set $true 1;<br>
>><br>
>> if ($true) {<br>
>> add_header X-Foo1 "bar";<br>
>> }<br>
>><br>
>> if ($true) {<br>
>> add_header X-Foo2 "bar";<br>
>> }<br>
>> }<br>
>><br>
>> добавит только один заголовок, X-Foo2. Эта особенность - что<br>
>> называется, не баг, а фича.<br>
>><br>
>> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,<br>
>> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных<br>
>> location'ов, пытаются наследовать директивы, которые в норме не<br>
>> наследуются во вложенные location'ы (e.g., proxy_pass). Иногда<br>
>> это получается, иногда - получается, но неправильно, иногда - не<br>
>> получается вовсе. Конкретные известные случаи нехорошего<br>
>> поведения - коллекционируются на страничке IfIsEvil.<br>
>><br>
>> --<br>
>> Maxim Dounin<br>
>> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>><br>
>><br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: "Васильев \"Zmey!\" Олег" <<a href="mailto:zmey1992@ya.ru">zmey1992@ya.ru</a>><br>
>> To: "<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>" <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>><br>
>> Cc:<br>
>> Date: Mon, 02 Sep 2013 04:53:03 +0400<br>
>> Subject: Re: If is Evil<br>
>> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на ряду с<br>
>> этими if-ами. Есть какой-то список директив, которые наследуются (или не<br>
>> наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы<br>
>> крайне полезный материал, т.к. в голове всё удержать не выходит.<br>
>><br>
>> 02.09.2013, 03:42, "Maxim Dounin" <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br>
>> > Hello!<br>
>> ><br>
>> > On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:<br>
>> ><br>
>> >> Приветы всем!<br>
>> >><br>
>> >> Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не<br>
>> >> рекомендуется, и что использовать его там можно только в купе с return<br>
>> >> или<br>
>> >> rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и<br>
>> >> почему.<br>
>> >><br>
>> >> Пару рабочих дней было потрачено на то, чтобы разобраться, как оно<br>
>> >> работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл,<br>
>> >> а все<br>
>> >> гуглы мира ведут на 3 ссылки:<br>
>> >><br>
>> >> <a href="http://wiki.nginx.org/IfIsEvil" target="_blank">http://wiki.nginx.org/IfIsEvil</a><br>
>> >> <a href="http://habrahabr.ru/post/74135/" target="_blank">http://habrahabr.ru/post/74135/</a><br>
>> >><br>
>> >> <a href="http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html" target="_blank">http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html</a><br>
>> >><br>
>> >> Но в первой кроме лирики толком ничего не сказано, вторая просто с<br>
>> >> первого<br>
>> >> же примера плавит мозг, а в последней уже куда по-лучше, примеров<br>
>> >> несколько.. но все одно - какой принцип отработки не ясно(<br>
>> >><br>
>> >> Ребят, может кто может подробно и последовательно разжевать, КАК это<br>
>> >> работает? А то пока получалось обходиться без if'ов, но кто его знает,<br>
>> >> что<br>
>> >> будет завтра.. не хотелось бы оставить новый след от граблей, старый<br>
>> >> только<br>
>> >> вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем<br>
>> >> просто<br>
>> >> запомнить постулат "скажем if в location - НЕТ"<br>
>> >><br>
>> >> Буду признателен за любые ответы. Спасибо!<br>
>> ><br>
>> > В первую голову - надо уяснить для себя, что if создаёт вложенный<br>
>> > location. И именно в этом location'е в результате будет обработан<br>
>> > запрос, если if выполнется. Если таких if'ов много - то запрос<br>
>> > будет обработан в последнем if'е, который выполнится. Поэтому<br>
>> > конфигурация вида<br>
>> ><br>
>> > location / {<br>
>> > set $true 1;<br>
>> ><br>
>> > if ($true) {<br>
>> > add_header X-Foo1 "bar";<br>
>> > }<br>
>> ><br>
>> > if ($true) {<br>
>> > add_header X-Foo2 "bar";<br>
>> > }<br>
>> > }<br>
>> ><br>
>> > добавит только один заголовок, X-Foo2. Эта особенность - что<br>
>> > называется, не баг, а фича.<br>
>> ><br>
>> > А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,<br>
>> > в первую очередь, с тем, что if'ы, в отличие от обычных вложенных<br>
>> > location'ов, пытаются наследовать директивы, которые в норме не<br>
>> > наследуются во вложенные location'ы (e.g., proxy_pass). Иногда<br>
>> > это получается, иногда - получается, но неправильно, иногда - не<br>
>> > получается вовсе. Конкретные известные случаи нехорошего<br>
>> > поведения - коллекционируются на страничке IfIsEvil.<br>
>> ><br>
>> > --<br>
>> > Maxim Dounin<br>
>> > <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > nginx-ru mailing list<br>
>> > <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> > <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
>><br>
>><br>
>><br>
>><br>
>> ---------- Пересылаемое сообщение ----------<br>
>> From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
>> To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> Cc:<br>
>> Date: Mon, 2 Sep 2013 05:16:01 +0400<br>
>> Subject: Re: Неправильные (огромные) значения $request time для<br>
>> FastCGI-запросов<br>
>> Hello!<br>
>><br>
>> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:<br>
>><br>
>> > А что, за год баг так и не исправили? Разрабы даже не удосужились здесь<br>
>> > отписаться? Баг хотябы в багтрекере висит?<br>
>> > Подтверждаю, у меня тоже $request_time выдаёт бред:<br>
>> ><br>
>> > 240648971536.2381542<br>
>> > 240648971536.2381542<br>
>> > 240648971536.2381542<br>
>> > 240648971536.2381542<br>
>> > 240648971536.2381542<br>
>> ><br>
>> > Одно и то же для многих запросов подряд, потом опять на другой бред<br>
>> > меняет!<br>
>> > Когда это исправят? Зачем в Nginx сделана переменная $request_time если<br>
>> > она<br>
>> > показывает всякий бред, мне думается её нужно убрать, а через несколько<br>
>> > лет,<br>
>> > когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше<br>
>> > вреда<br>
>> > чем пользы.<br>
>> ><br>
>> > P.S. Использую Windows и PHP как FastCGI.<br>
>><br>
>> Я даже и не знаю, что вам сказать. Привыкайте - это open source.<br>
>> Тут вам никто ничего не должен, и править вылезающие у вас баги -<br>
>> вам. Надеяться, что кто-то придёт, и за вас исправит, тем более<br>
>> на Windows - по меньшей мере наивно.<br>
>><br>
>> Впрочем, патч:<br>
>><br>
>> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c<br>
>> --- a/src/http/modules/ngx_http_log_module.c Thu Aug 29 20:39:13 2013<br>
>> +0400<br>
>> +++ b/src/http/modules/ngx_http_log_module.c Mon Sep 02 04:38:34 2013<br>
>> +0400<br>
>> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque<br>
>> ((tp->sec - r->start_sec) * 1000 + (tp->msec -<br>
>> r->start_msec));<br>
>> ms = ngx_max(ms, 0);<br>
>><br>
>> - return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);<br>
>> + return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);<br>
>> }<br>
>><br>
>><br>
>> diff -r 683283f8b5fd src/http/ngx_http_variables.c<br>
>> --- a/src/http/ngx_http_variables.c Thu Aug 29 20:39:13 2013 +0400<br>
>> +++ b/src/http/ngx_http_variables.c Mon Sep 02 04:38:34 2013 +0400<br>
>> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_<br>
>> ((tp->sec - r->start_sec) * 1000 + (tp->msec -<br>
>> r->start_msec));<br>
>> ms = ngx_max(ms, 0);<br>
>><br>
>> - v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;<br>
>> + v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) -<br>
>> p;<br>
>> v->valid = 1;<br>
>> v->no_cacheable = 0;<br>
>> v->not_found = 0;<br>
>><br>
>> --<br>
>> Maxim Dounin<br>
>> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> nginx-ru mailing list<br>
>> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br></blockquote></div><br></div>