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