ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nginx-ru Digest, Vol 47, Issue 4


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: nginx-ru Digest, Vol 47, Issue 4
  • From: Андрей Середенко <andrei.seredenko@xxxxxxxxx>
  • Date: Mon, 2 Sep 2013 11:38:22 +0300
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=y55J2qpN+/aU2ca/0Z+LltW5zEvPo39NyR/+vgARL+w=; b=Y4dL6WDxH1ZDBTNd5Niv3hJaMuuQXZ6WVvYL9GGvxTzwCK347uF0ztpKc6yLaBGLQg XAxrwrj6MO/wjH6rYVGU/Slh7j17tfVPqxiFdv8XX6Mjv4Yke01Qt0+MsZaTI02G6sHa bEShTUW4CWlXK2RdvNFCJBKIm1kMT7UcY3M4lhp+v6LgXX0z2KpyQIM7pZkR1n7Va4g8 Ps1KUX3klcvlekGa58cuZqRhVAw1KAh/H88hFlRu+ovlx8wSa47MMLsQ0GsjNLqiyaPM FS/a4DxmyGcbNgT6PoAo7WsZ+/lFSM6L9LHE4jtwSMsGIwsLItYRWUr3WXaZgqag6vtm xdQQ==
  • In-reply-to: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>
  • References: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>

В таком случае, если отрабатывает только последний из 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@xxxxxxxxx> написал:
Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
отправлять по адресу
        nginx-ru@xxxxxxxxx

Для изменения параметров подписки вы можеже использовать веб-страницу
        http://mailman.nginx.org/mailman/listinfo/nginx-ru

Для получения информации о том, как пользовать почтовым интерфейсом,
отправьте письмо, в теле или теме которого будет слово 'help', по
адресу:
        nginx-ru-request@xxxxxxxxx

Адрес человека, ответственного за этот список рассылки:
        nginx-ru-owner@xxxxxxxxx

При ответе, пожалуйста, измение тему письма так, чтобы она была более
содержательной чем "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@xxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxx>
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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru



--
Yours sincerely,
Vladimir Getmanshchuk


---------- Пересылаемое сообщение ----------
From: "locojohn" <nginx-forum@xxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxx>
To: nginx-ru <nginx-ru@xxxxxxxxx>
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@xxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxx>
To: "nginx-ru@xxxxxxxxx" <nginx-ru@xxxxxxxxx>
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@xxxxxxxxxx>:
> 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@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




---------- Пересылаемое сообщение ----------
From: Maxim Dounin <mdounin@xxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.