В данной конфигурации нужно выкинуть все if и сделать map + if. Либо использовать allow+deny, как это обычно делают.
2013/9/2 Андрей Середенко <[email protected]>: > В таком случае, если отрабатывает только последний из 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 пользователь <[email protected]> написал: >> >> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо >> отправлять по адресу >> [email protected] >> >> Для изменения параметров подписки вы можеже использовать веб-страницу >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> Для получения информации о том, как пользовать почтовым интерфейсом, >> отправьте письмо, в теле или теме которого будет слово 'help', по >> адресу: >> [email protected] >> >> Адрес человека, ответственного за этот список рассылки: >> [email protected] >> >> При ответе, пожалуйста, измение тему письма так, чтобы она была более >> содержательной чем "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 <[email protected]> >> To: [email protected] >> 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 Валентин Бартенев <[email protected]> >>> >>> 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 >>> [email protected] >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> >> -- >> Yours sincerely, >> Vladimir Getmanshchuk >> >> >> ---------- Пересылаемое сообщение ---------- >> From: "locojohn" <[email protected]> >> To: [email protected] >> 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 <[email protected]> >> To: nginx-ru <[email protected]> >> 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: "Валентин Бартенев" <[email protected]> >> To: [email protected] >> 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: "Валентин Бартенев" <[email protected]> >> To: [email protected] >> 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 <[email protected]> >> To: [email protected] >> 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!\" Олег" <[email protected]> >> To: "[email protected]" <[email protected]> >> 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" <[email protected]>: >> > 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 >> > [email protected] >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> >> ---------- Пересылаемое сообщение ---------- >> From: Maxim Dounin <[email protected]> >> To: [email protected] >> 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 >> [email protected] >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
