В таком случае, если отрабатывает только последний из 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-requ...@nginx.org> написал: > Сообщения, предназначенные для списка рассылки nginx-ru, необходимо > отправлять по адресу > nginx-ru@nginx.org > > Для изменения параметров подписки вы можеже использовать веб-страницу > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Для получения информации о том, как пользовать почтовым интерфейсом, > отправьте письмо, в теле или теме которого будет слово 'help', по > адресу: > nginx-ru-requ...@nginx.org > > Адрес человека, ответственного за этот список рассылки: > nginx-ru-ow...@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 <vlad...@gmail.com> > To: nginx-ru@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 Валентин Бартенев <n...@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@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > > > ---------- Пересылаемое сообщение ---------- > From: "locojohn" <nginx-fo...@nginx.us> > To: nginx-ru@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 <onoko...@gmail.com> > To: nginx-ru <nginx-ru@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: "Валентин Бартенев" <vb...@nginx.com> > To: nginx-ru@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: "Валентин Бартенев" <vb...@nginx.com> > To: nginx-ru@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 <mdou...@mdounin.ru> > To: nginx-ru@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!\" Олег" <zmey1...@ya.ru> > To: "nginx-ru@nginx.org" <nginx-ru@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" <mdou...@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@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > ---------- Пересылаемое сообщение ---------- > From: Maxim Dounin <mdou...@mdounin.ru> > To: nginx-ru@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru >
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru