<div dir="ltr"><div>В таком случае, если отрабатывает только последний из if'ов - то в данной конфигурации:<br><br> location ~* /test/url/Page.asmx {</div><div> proxy_pass <a href="http://test_upstream">http://test_upstream</a>;</div>
<div> proxy_redirect off;</div><div> proxy_set_header Host $host;</div><div> proxy_set_header Remote-Addr $remote_addr;</div><div> proxy_set_header X-Real-IP $remote_addr;</div>
<div> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;</div><div> proxy_set_header X-Public-Url http://$host$request_uri;</div><div style> ...<br> some other proxy options</div>
<div style> ...</div><div> #</div><div> set $my_ipsrc 0;</div><div> # allow <a href="http://10.10.1.75/32">10.10.1.75/32</a>;</div><div> if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }</div>
<div> # allow <a href="http://10.20.1.20/32">10.20.1.20/32</a>;</div><div> if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }</div><div> # allow <a href="http://10.20.1.21/32">10.20.1.21/32</a>;</div>
<div> if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }</div><div> # allow <a href="http://10.100.1.0/24">10.100.1.0/24</a>;<br></div><div><div> if ($remote_addr = <a href="http://10.100.1.0/24">10.100.1.0/24</a>) { set $my_ipsrc 1; }</div>
<div> # allow <a href="http://178.111.122.133/32">178.111.122.133/32</a>;</div><div> if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }</div><div> # deny all;</div><div> if ($my_ipsrc = 0) { return 500; }</div>
<div> }</div></div><div style><br>всем, кроме последнего адреса, должно возвращаться "500" ?<br>или лыжи не едут? :)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2 сентября 2013 г., 4:16 пользователь <span dir="ltr"><<a href="mailto:nginx-ru-request@nginx.org" target="_blank">nginx-ru-request@nginx.org</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Сообщения, предназначенные для списка рассылки nginx-ru, необходимо<br>
отправлять по адресу<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<br>
Для изменения параметров подписки вы можеже использовать веб-страницу<br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>
Для получения информации о том, как пользовать почтовым интерфейсом,<br>
отправьте письмо, в теле или теме которого будет слово 'help', по<br>
адресу:<br>
<a href="mailto:nginx-ru-request@nginx.org">nginx-ru-request@nginx.org</a><br>
<br>
Адрес человека, ответственного за этот список рассылки:<br>
<a href="mailto:nginx-ru-owner@nginx.org">nginx-ru-owner@nginx.org</a><br>
<br>
При ответе, пожалуйста, измение тему письма так, чтобы она была более<br>
содержательной чем "Re: Содержание дайджеста списка рассылки<br>
nginx-ru..."<br>
<br>Today's Topics:<br>
<br>
1. Re: true 414 status code (Vladimir Getmanshchuk)<br>
2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)<br>
3. Re: If is Evil (Daniel Podolsky)<br>
4. Re: true 414 status code (Валентин Бартенев)<br>
5. Re: true 414 status code (Валентин Бартенев)<br>
6. Re: If is Evil (Maxim Dounin)<br>
7. Re: If is Evil (Васильев Zmey! Олег)<br>
8. Re: Неправильные (огромные) значения $request time для<br>
FastCGI-запросов (Maxim Dounin)<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Vladimir Getmanshchuk <<a href="mailto:vladget@gmail.com">vladget@gmail.com</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>Cc: <br>
Date: Sun, 1 Sep 2013 23:33:57 +0300<br>Subject: Re: true 414 status code<br><div dir="ltr">Амм... Спасибо за скорость и лаконичность.<div><br><div><div>Судя по <a href="http://www.w3.org/Protocols/HTTP/HTRESP.html" target="_blank">http://www.w3.org/Protocols/HTTP/HTRESP.html</a>, в HTTP/0.9 тоже есть status codes, или я что то недопонимаю?</div>
<div>Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"</div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/31 Валентин Бартенев <span dir="ltr"><<a href="mailto:ne@vbart.ru" target="_blank">ne@vbart.ru</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:<br>
> Здравствуйте!<br>
><br>
> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414<br>
> status code, на запросы, размер которых, превышает large_client_header_<br>
> buffers?<br>
><br>
> Постоянно получаю 200 http status code и нижеприведенное в body:<br>
><br>
> <html><br>
> <head><title>414 Request-URI Too Large</title></head><br>
> <body bgcolor="white"><br>
> <center><h1>414 Request-URI Too Large</h1></center><br>
> <hr><center>nginx/1.2.9</center><br>
> </body><br>
> </html><br>
<br>
</div></div>Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.<br>
<br>
--<br>
Валентин Бартенев<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div><br><br clear="all"><div><br></div>-- <br>Yours sincerely,<br>Vladimir Getmanshchuk
</div>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "locojohn" <<a href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Sun, 01 Sep 2013 16:44:45 -0400<br>Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)<br>Oleksandr V. Typlyns'kyi Wrote:<br>
<br>
> Как видно из кода стороннего модуля(а туда тоже следовало бы<br>
> посмотреть),<br>
> там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог<br>
> ошибок.<br>
> И они явно намекают на content type который теперь<br>
> application/javascript.<br>
> Добавление его в concat_types должно помочь.<br>
<br>
Спасибо за отличный хинт! Добавление "application/javascript" в<br>
concat_types не помогло, пришлось подпатчить исходный модуль concat:<br>
<br>
--- ngx_http_concat_module.c<br>
+++ ngx_http_concat_module.c<br>
@@ -30,7 +30,7 @@<br>
<br>
<br>
static ngx_str_t ngx_http_concat_default_types[] = {<br>
- ngx_string("application/x-javascript"),<br>
+ ngx_string("application/javascript"),<br>
ngx_string("text/css"),<br>
ngx_null_string<br>
};<br>
<br>
Ещё раз - спасибо!<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?21,242399,242424#msg-242424" target="_blank">http://forum.nginx.org/read.php?21,242399,242424#msg-242424</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Daniel Podolsky <<a href="mailto:onokonem@gmail.com">onokonem@gmail.com</a>><br>To: nginx-ru <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>><br>
Cc: <br>Date: Mon, 2 Sep 2013 00:47:34 +0400<br>Subject: Re: If is Evil<br>> да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить<br>
> постулат "скажем if в location - НЕТ"<br>
А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый<br>
location, и что туда наследуется, а что нет, и какая там в результате<br>
будет конфигурациия - ни за что не прописаешь, как говорили в школе.<br>
<br>
Поэтому мы пользуемся if, но только одним образом - делаем на нем<br>
переадресацию в именованный локейшн.<br>
<br>
Отдельно, конечно, смешно то, что это единственный разумный способ<br>
пользоваться if, но директивы переадресации как не было, так и нет, и<br>
приходится писать что-то вроде if (condition) { error_page 418 =<br>
@location; return 418; }<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Валентин Бартенев" <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Mon, 2 Sep 2013 03:02:45 +0400<br>Subject: Re: true 414 status code<br>On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:<br>
> Амм... Спасибо за скорость и лаконичность.<br>
><br>
> Судя по <a href="http://www.w3.org/Protocols/HTTP/HTRESP.html" target="_blank">http://www.w3.org/Protocols/HTTP/HTRESP.html</a>, в HTTP/0.9 тоже есть<br>
> status codes, или я что то недопонимаю?<br>
<br>
Вы ссылаетесь на спецификацию HTTP/1.0. В HTTP/0.9 у ответа не было заголовка:<br>
<a href="http://www.w3.org/Protocols/HTTP/AsImplemented.html" target="_blank">http://www.w3.org/Protocols/HTTP/AsImplemented.html</a><br>
<a href="http://www.w3.org/DesignIssues/HTTP0.9Summary.html" target="_blank">http://www.w3.org/DesignIssues/HTTP0.9Summary.html</a><br>
<br>
<br>
> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"<br>
<br>
Сам дописывает видимо. Смотрите более простыми средствами, типа netcat'а или<br>
telnet'а.<br>
<br>
--<br>
Валентин Бартенев<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Валентин Бартенев" <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
Cc: <br>Date: Mon, 2 Sep 2013 03:08:04 +0400<br>Subject: Re: true 414 status code<br>On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:<br>
> On <a href="tel:31.08.2013%2023" value="+13108201323">31.08.2013 23</a>:57, Валентин Бартенев wrote:<br>
> >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414<br>
> >> status code, на запросы, размер которых, превышает large_client_header_<br>
> >> buffers?<br>
> >><br>
> >> Постоянно получаю 200 http status code и нижеприведенное в body:<br>
> >><br>
> >> <html><br>
> >> <head><title>414 Request-URI Too Large</title></head><br>
> >> <body bgcolor="white"><br>
> >> <center><h1>414 Request-URI Too Large</h1></center><br>
> >> <hr><center>nginx/1.2.9</center><br>
> >> </body><br>
> >> </html><br>
> ><br>
> > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.<br>
><br>
> а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?<br>
> тем более, что запрос в 99.9999999% был версии 1.0 или 1.1<br>
><br>
> даже если "Request-URI Too Large" - версию протокола<br>
> запроса можно узнать из строки запроса, при желании.<br>
<br>
Нельзя. В наихудшим случае (а он обязательно наступит)<br>
строка запроса будет бесконечна.<br>
<br>
><br>
> тем более, что протокол версии 0.9 не умеет прислать<br>
> клиенту ответ в котором будет указан status code 414<br>
><br>
> а парсить тело ответа веб-сервера никто не будет,<br>
> различных серверов много и формат ответов разный.<br>
<br>
Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже<br>
прислал коллегам соответствующий патч на ревью.<br>
<br>
--<br>
Валентин Бартенев<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>Cc: <br>Date: Mon, 2 Sep 2013 03:42:31 +0400<br>
Subject: Re: If is Evil<br>Hello!<br>
<br>
On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:<br>
<br>
> Приветы всем!<br>
><br>
> Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не<br>
> рекомендуется, и что использовать его там можно только в купе с return или<br>
> rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и<br>
> почему.<br>
><br>
> Пару рабочих дней было потрачено на то, чтобы разобраться, как оно<br>
> работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а все<br>
> гуглы мира ведут на 3 ссылки:<br>
><br>
> <a href="http://wiki.nginx.org/IfIsEvil" target="_blank">http://wiki.nginx.org/IfIsEvil</a><br>
> <a href="http://habrahabr.ru/post/74135/" target="_blank">http://habrahabr.ru/post/74135/</a><br>
> <a href="http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html" target="_blank">http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html</a><br>
><br>
> Но в первой кроме лирики толком ничего не сказано, вторая просто с первого<br>
> же примера плавит мозг, а в последней уже куда по-лучше, примеров<br>
> несколько.. но все одно - какой принцип отработки не ясно(<br>
><br>
> Ребят, может кто может подробно и последовательно разжевать, КАК это<br>
> работает? А то пока получалось обходиться без if'ов, но кто его знает, что<br>
> будет завтра.. не хотелось бы оставить новый след от граблей, старый только<br>
> вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем просто<br>
> запомнить постулат "скажем if в location - НЕТ"<br>
><br>
> Буду признателен за любые ответы. Спасибо!<br>
<br>
В первую голову - надо уяснить для себя, что if создаёт вложенный<br>
location. И именно в этом location'е в результате будет обработан<br>
запрос, если if выполнется. Если таких if'ов много - то запрос<br>
будет обработан в последнем if'е, который выполнится. Поэтому<br>
конфигурация вида<br>
<br>
location / {<br>
set $true 1;<br>
<br>
if ($true) {<br>
add_header X-Foo1 "bar";<br>
}<br>
<br>
if ($true) {<br>
add_header X-Foo2 "bar";<br>
}<br>
}<br>
<br>
добавит только один заголовок, X-Foo2. Эта особенность - что<br>
называется, не баг, а фича.<br>
<br>
А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,<br>
в первую очередь, с тем, что if'ы, в отличие от обычных вложенных<br>
location'ов, пытаются наследовать директивы, которые в норме не<br>
наследуются во вложенные location'ы (e.g., proxy_pass). Иногда<br>
это получается, иногда - получается, но неправильно, иногда - не<br>
получается вовсе. Конкретные известные случаи нехорошего<br>
поведения - коллекционируются на страничке IfIsEvil.<br>
<br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: "Васильев \"Zmey!\" Олег" <<a href="mailto:zmey1992@ya.ru">zmey1992@ya.ru</a>><br>To: "<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>" <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>><br>
Cc: <br>Date: Mon, 02 Sep 2013 04:53:03 +0400<br>Subject: Re: If is Evil<br>Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на ряду с этими if-ами. Есть какой-то список директив, которые наследуются (или не наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы крайне полезный материал, т.к. в голове всё удержать не выходит.<br>
<br>
02.09.2013, 03:42, "Maxim Dounin" <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br>
> Hello!<br>
><br>
> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:<br>
><br>
>> Приветы всем!<br>
>><br>
>> Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не<br>
>> рекомендуется, и что использовать его там можно только в купе с return или<br>
>> rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и<br>
>> почему.<br>
>><br>
>> Пару рабочих дней было потрачено на то, чтобы разобраться, как оно<br>
>> работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а все<br>
>> гуглы мира ведут на 3 ссылки:<br>
>><br>
>> <a href="http://wiki.nginx.org/IfIsEvil" target="_blank">http://wiki.nginx.org/IfIsEvil</a><br>
>> <a href="http://habrahabr.ru/post/74135/" target="_blank">http://habrahabr.ru/post/74135/</a><br>
>> <a href="http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html" target="_blank">http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html</a><br>
>><br>
>> Но в первой кроме лирики толком ничего не сказано, вторая просто с первого<br>
>> же примера плавит мозг, а в последней уже куда по-лучше, примеров<br>
>> несколько.. но все одно - какой принцип отработки не ясно(<br>
>><br>
>> Ребят, может кто может подробно и последовательно разжевать, КАК это<br>
>> работает? А то пока получалось обходиться без if'ов, но кто его знает, что<br>
>> будет завтра.. не хотелось бы оставить новый след от граблей, старый только<br>
>> вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем просто<br>
>> запомнить постулат "скажем if в location - НЕТ"<br>
>><br>
>> Буду признателен за любые ответы. Спасибо!<br>
><br>
> В первую голову - надо уяснить для себя, что if создаёт вложенный<br>
> location. И именно в этом location'е в результате будет обработан<br>
> запрос, если if выполнется. Если таких if'ов много - то запрос<br>
> будет обработан в последнем if'е, который выполнится. Поэтому<br>
> конфигурация вида<br>
><br>
> location / {<br>
> set $true 1;<br>
><br>
> if ($true) {<br>
> add_header X-Foo1 "bar";<br>
> }<br>
><br>
> if ($true) {<br>
> add_header X-Foo2 "bar";<br>
> }<br>
> }<br>
><br>
> добавит только один заголовок, X-Foo2. Эта особенность - что<br>
> называется, не баг, а фича.<br>
><br>
> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,<br>
> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных<br>
> location'ов, пытаются наследовать директивы, которые в норме не<br>
> наследуются во вложенные location'ы (e.g., proxy_pass). Иногда<br>
> это получается, иногда - получается, но неправильно, иногда - не<br>
> получается вовсе. Конкретные известные случаи нехорошего<br>
> поведения - коллекционируются на страничке IfIsEvil.<br>
><br>
> --<br>
> Maxim Dounin<br>
> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
<br>
<br>
<br><br>---------- Пересылаемое сообщение ----------<br>From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>To: <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>Cc: <br>Date: Mon, 2 Sep 2013 05:16:01 +0400<br>
Subject: Re: Неправильные (огромные) значения $request time для FastCGI-запросов<br>Hello!<br>
<br>
On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:<br>
<br>
> А что, за год баг так и не исправили? Разрабы даже не удосужились здесь<br>
> отписаться? Баг хотябы в багтрекере висит?<br>
> Подтверждаю, у меня тоже $request_time выдаёт бред:<br>
><br>
> 240648971536.2381542<br>
> 240648971536.2381542<br>
> 240648971536.2381542<br>
> 240648971536.2381542<br>
> 240648971536.2381542<br>
><br>
> Одно и то же для многих запросов подряд, потом опять на другой бред меняет!<br>
> Когда это исправят? Зачем в Nginx сделана переменная $request_time если она<br>
> показывает всякий бред, мне думается её нужно убрать, а через несколько лет,<br>
> когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше вреда<br>
> чем пользы.<br>
><br>
> P.S. Использую Windows и PHP как FastCGI.<br>
<br>
Я даже и не знаю, что вам сказать. Привыкайте - это open source.<br>
Тут вам никто ничего не должен, и править вылезающие у вас баги -<br>
вам. Надеяться, что кто-то придёт, и за вас исправит, тем более<br>
на Windows - по меньшей мере наивно.<br>
<br>
Впрочем, патч:<br>
<br>
diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c<br>
--- a/src/http/modules/ngx_http_log_module.c Thu Aug 29 20:39:13 2013 +0400<br>
+++ b/src/http/modules/ngx_http_log_module.c Mon Sep 02 04:38:34 2013 +0400<br>
@@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque<br>
((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));<br>
ms = ngx_max(ms, 0);<br>
<br>
- return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);<br>
+ return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);<br>
}<br>
<br>
<br>
diff -r 683283f8b5fd src/http/ngx_http_variables.c<br>
--- a/src/http/ngx_http_variables.c Thu Aug 29 20:39:13 2013 +0400<br>
+++ b/src/http/ngx_http_variables.c Mon Sep 02 04:38:34 2013 +0400<br>
@@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_<br>
((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));<br>
ms = ngx_max(ms, 0);<br>
<br>
- v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;<br>
+ v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) - p;<br>
v->valid = 1;<br>
v->no_cacheable = 0;<br>
v->not_found = 0;<br>
<br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br>
<br>
<br>_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br></blockquote></div><br></div>