nginx-ru Digest, Vol 47, Issue 4
Андрей Середенко
andrei.seredenko at gmail.com
Mon Sep 2 08:38:22 UTC 2013
В таком случае, если отрабатывает только последний из 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/bdeb0e0f/attachment-0001.html>
Подробная информация о списке рассылки nginx-ru