Lexa Software: Nginx-ru@sysoev.ru archive

2 сентября 2013 г., 13:42 пользователь <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: nginx-ru Digest, Vol 47, Issue 4 (Maxim Dounin)
2. Re: nginx-ru Digest, Vol 47, Issue 6 (Андрей Середенко)

---------- Пересылаемое сообщение ----------
From: Maxim Dounin <mdounin@xxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@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. 502 уступили место 504 (DenisM)
2. Re: nginx-ru Digest, Vol 47, Issue 4 (Alexander Moskalenko)

---------- Пересылаемое сообщение ----------
From: "DenisM" <nginx-forum@xxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxx>
To: nginx-ru <nginx-ru@xxxxxxxxx>
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@xxxxxxxxx>:
> В таком случае, если отрабатывает только последний из 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

_______________________________________________
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

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