Re: Помогите с rewrite
Не уверен, но мне кажется вот так: return http://somesite.com/directory/$arg_arg1/$arg_arg2 301; http://nginx.org/en/docs/http/ngx_http_core_module.html#variables On Sat, Jul 6, 2019 at 5:43 PM Dmytro Lavryk wrote: > Чего-то видимо туплю. Подскажите как такое организовать: > есть урл вида http://somesite.com/directory/?arg1=SOME-ARG1&arg2=SOME-ARG2 > нужно получить редирект на > http://somesite.com/directory/SOME-ARG1/SOME-ARG2 > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,284765,284765#msg-284765 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Влияние на производительность проверок на существоание файла (-f) в rewrite модуле
Кстати конструкцию можно сильно упростить через try_files
/maintenance_on.html ... ;
On Thu, May 23, 2019 at 3:44 PM Maxim Dounin wrote:
> Hello!
>
> On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:
>
> > Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять
> > на произовдительность конструкция:
> >
> > > location / {
> > > if (-f /var/www/maintenance_on.html) {
> > > return 503;
> > > }
> > >
> > >
> > > ...
> > > }
> > >
> > >
> > > # Error pages.
> > > error_page 503 /maintenance_on.html;
> > > location = /maintenance_on.html {
> > > root /var/www;
> > > }
> > Например 7-10 location с такими проверками на хосте 4K запросов в
> секунду?
> > На каждый запрос он будет проверять существование файла? Или как-то это
> > делает по таймауту, который можно настроить?
>
> При такой конфигурации на каждый запрос[*] будет делаться
> системный вызов stat(). Скорее всего необходимые данные будут в
> кэше операционной системы, и этот системный вызов будет быстрым,
> так что на производительности это скажется минимально.
>
> Так что если речь не идёт о борьбе за каждый процент - про
> производительность подобной конструкции можно не переживать.
> Другой вопрос, что сама по себе конструкция не очень, выкатку
> нужно уметь делать без перерывов в обслуживании.
>
> [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а,
> чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache).
> Но практика показывает, что на производительность это влияет
> минимально, а вот выстрелить себе в ногу неатомарным изменением
> файлов станет легко.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: epoll_ctl: file exists ?
Максим, если найдете свободную минуту - расскажите пожалуйста почему. Спасибо. On Tue, Apr 30, 2019 at 5:39 PM Maxim Dounin wrote: > Hello! > > On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote: > > > привет, > > > > насколько опасно вот такое ? > > > > > > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188) > failed > > (17: File exists) while proxying upgraded connection, client: > > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/ > HTTP/2.0", > > upstream: "http://192.168.188.40:2339/wsapi/";, host: "xxx.xxx.xxx" > > Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2. > Работать - не будет. > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: специальные символы в запросах
ИМХО, вы не тем занимаетесь, боритесь с XSS на backend + хидер для
браузеров:
# This header enables the Cross-site scripting (XSS) filter built into most
recent web browsers.
# It's usually enabled by default anyway, so the role of this header is to
re-enable the filter for
# this particular website if it was disabled by the user.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
add_header X-XSS-Protection "1; mode=block";
On Tue, Apr 23, 2019 at 9:57 AM anatolr wrote:
> Пытаюсь закрыть выполнение такого вида запросов к сайту
> содержащих специальный символ < или >
>
> http://www.host.ru/index.php/>
> document.body.style.backgroundImage=url('http://
> .../orig_.jpg')";
>
> делаю с помощью
>
> location ~* ^(.*)(\<)+(.*)$ {
> return 404;
> }
>
> но запрос не перехватывается код > 3C
>
> пробовал в hex кодe как-то так (.*)[^\3С]+(.*)
>
> как правильно указать в location такого вида символы?
>
> Прошу помогите пожайлуста как запретить такие строки в nginx?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,283878,283878#msg-283878
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: underscores_in_headers - баг в документации ?
Все, теперь понял о чем вы. Действительно неправильная формулировка.
пт, 12 квіт. 2019 о 16:47 Илья Шипицин пише:
> "Если директива указана на уровне server
> <https://nginx.org/ru/docs/http/ngx_http_core_module.html#server>, её
> значение используется только в том случае, если сервер является сервером по
> умолчанию. Указанное значение распространяется на все виртуальные серверы,
> слушающие на том же адресе и порту."
>
> документация. не поправили
>
> пт, 12 апр. 2019 г. в 18:40, Vladimir Getmanshchuk :
>
>> Не понимаю в чем баг, underscores_in_headers работает в контексте server
>> где она описана.
>>
>> On Wed, Apr 10, 2019 at 2:25 PM Sergey Kandaurov
>> wrote:
>>
>>>
>>> > On 9 Apr 2019, at 23:31, Илья Шипицин wrote:
>>> >
>>> > привет!
>>> >
>>> > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах
>>> (не спрашивайте, у меня нет идей, чем заправлялись разработчики)
>>> >
>>> > читаем
>>> >
>>> >
>>> https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers
>>> >
>>> > ок. директиву надо писать в дефолт сервере.
>>> > пишем
>>> >
>>> > log_format underscore '$http_header_underscore\t$status';
>>> >
>>> > server {
>>> > listen 80;
>>> > server_name localhost;
>>> >
>>> > access_log /var/log/nginx/test.log underscore;
>>> >
>>> > location / {
>>> > proxy_pass http://127.0.0.1:81;
>>> > }
>>> >
>>> > }
>>> >
>>> > server {
>>> > listen 80 default_server;
>>> > server_name _;
>>> >
>>> > underscores_in_headers on;
>>> >
>>> > location / { return 404; }
>>> > }
>>> >
>>> > server {
>>> > listen 81;
>>> > server_name localhost;
>>> >
>>> > location / { return 418; }
>>> >
>>> > }
>>> >
>>> >
>>> >
>>> > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает.
>>> > зато, если добавить в соответствующий сервер - работает.
>>> >
>>> > баг ?
>>>
>>> Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0
>>> Видимо, забыли поправить документацию.
>>>
>>> --
>>> Sergey Kandaurov
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> --
>> Yours sincerely,
>> Vladimir Getmanshchuk
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: underscores_in_headers - баг в документации ?
Не понимаю в чем баг, underscores_in_headers работает в контексте server
где она описана.
On Wed, Apr 10, 2019 at 2:25 PM Sergey Kandaurov wrote:
>
> > On 9 Apr 2019, at 23:31, Илья Шипицин wrote:
> >
> > привет!
> >
> > допустим, у нас своеобразное приложение. с подчеркиванием в хедерах (не
> спрашивайте, у меня нет идей, чем заправлялись разработчики)
> >
> > читаем
> >
> >
> https://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers
> >
> > ок. директиву надо писать в дефолт сервере.
> > пишем
> >
> > log_format underscore '$http_header_underscore\t$status';
> >
> > server {
> > listen 80;
> > server_name localhost;
> >
> > access_log /var/log/nginx/test.log underscore;
> >
> > location / {
> > proxy_pass http://127.0.0.1:81;
> > }
> >
> > }
> >
> > server {
> > listen 80 default_server;
> > server_name _;
> >
> > underscores_in_headers on;
> >
> > location / { return 404; }
> > }
> >
> > server {
> > listen 81;
> > server_name localhost;
> >
> > location / { return 418; }
> >
> > }
> >
> >
> >
> > можете проверить (я проверял на 1.15.11 без доп модулей) - не работает.
> > зато, если добавить в соответствующий сервер - работает.
> >
> > баг ?
>
> Нет, изменение поведения: hg.nginx.org/nginx/rev/c4d3310574e0
> Видимо, забыли поправить документацию.
>
> --
> Sergey Kandaurov
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
Работает в проде на нагрузках 1K rps. Проблем нет. On Mon, Feb 11, 2019 at 9:41 AM Иван wrote: > Здравствуйте! > > Про конвертацию в формат доступный для geo прям свежая идея! Не > подскажете, "выдюжит" geo-модуль geoip данные по городам? Там будет ~150 > 000 записей. > > Быть может у вас есть наработки для конвертации? > > С уважением, Иван. > > 11.02.2019 04:05, Maxim Dounin пишет: > > Hello! > > > > On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > > > >> а какое-то развитие родного модуля будет с учетом новостей от MaxMind? > > http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html > > > > [...] > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
Угу, все в этом треде, используйте вторую версию... On Thu, Feb 7, 2019 at 10:09 PM Илья Шипицин wrote: > я один прозевал новость, что GeoLite всё ? )) > > https://support.maxmind.com/geolite-legacy-discontinuation-notice/ > > чт, 10 янв. 2019 г. в 19:47, Oleg A. Mamontov : > >> On Thu, Jan 10, 2019 at 08:53:12AM -0500, kycedbi wrote: >> >> В данный момент рассматривается вопрос доработки ngx_http_geoip_module >> >> для поддержки MaxMind GeoIP2, но пока это из области возможных планов >> >> с неопределенными сроками. >> >Благодарю за информацию. >> >А в nginx, случаем, нету программы, с помощью которой можно было бы >> ускорить >> >реализацию некоторого функционала за донаты? >> >> Нет, программы такого формата у нас не существует, но качественные >> предложения по дополнению функциональности от сообщества охотно >> принимаются, подробнее можно прочитать тут: >> http://nginx.org/ru/docs/contributing_changes.html >> >> -- >> Cheers, >> Oleg A. Mamontov >> >> mailto: o...@mamontov.net >> >> skype: lonerr11 >> cell: +7 (903) 798-1352 >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
Всем спасибо за ответы. Гена, с City скрипт тоже корректно работает? On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: > On 04.01.2019 17:12, Vladimir Getmanshchuk wrote: > > > Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, > > в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и > > nginx. > > Разъясните пожалуйста ситуацию. > > > > Как я все это вижу: > > У maxmind была коммерческая GeoIP библиотека данных и программная > > библиотека для работы с ней, > > так же была бесплатная, но не очень точная библиотека данных под > названием > > GeoLite. > > Nginx работал с обоими этими либами через ngx_http_geoip_module... > > Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а > > так-же бесплатной либы под названием GeoLite2 и отказался от поддержки > > первой версии, > > а вчера вообще дропнул файлы со своих серверов. > > > > Все ли так? > > Поддерживает ли ngx_http_geoip_module GeoLite2? > > Если нет, то планируется ли разработка поддержки? > > Какие есть альтернативы maxmind и/или этому модулю? > > Есть альтернативы модулю ngx_http_geoip_module. > > Я просто конвертирую GeoLite2 в формат, который понимает nginx > с помощью своего скрипта https://github.com/makhomed/nginx-geo > запускаемого через крон раз в сутки, так что таким образом > у меня в nginx используется всегда самая свежая база GeoLite2 > через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html > > Встроенный в nginx модуль ngx_http_geo_module не использует никаких > сторонних библиотек, так что он работает максимально стабильно > и надежно, при этом использует минимальное количество памяти. > > -- > Best regards, > Gena > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
GeoIP
Добрый день! Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и nginx. Разъясните пожалуйста ситуацию. Как я все это вижу: У maxmind была коммерческая GeoIP библиотека данных и программная библиотека для работы с ней, так же была бесплатная, но не очень точная библиотека данных под названием GeoLite. Nginx работал с обоими этими либами через ngx_http_geoip_module... Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а так-же бесплатной либы под названием GeoLite2 и отказался от поддержки первой версии, а вчера вообще дропнул файлы со своих серверов. Все ли так? Поддерживает ли ngx_http_geoip_module GeoLite2? Если нет, то планируется ли разработка поддержки? Какие есть альтернативы maxmind и/или этому модулю? -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL lags
Ага, спасибо, че-то я сам всем советую, а сам забываю...
Вообщем после TCP handshake 0.1s пауза от curl, а потом только TSLv1.2
Client Hello
On Thu, Nov 29, 2018 at 1:09 PM Илья Шипицин wrote:
> так срисуйте tcpdump/wireshark
> оно же с раскладкой по времени все пакеты покажет
>
> (в случае https прекрасно видна стадия установки соединения)
>
> чт, 29 нояб. 2018 г. в 15:44, Vladimir Getmanshchuk :
>
>> Очень похоже это какой-то глюк curl(запускаю с той же машины),
>> я тут случайно сделал time wget https://server/object, и вот что получил:
>>
>> WGET
>> real 0m0.004s (http)
>> real 0m0.012s (https)
>> CURL
>> real 0m0.012s (http)
>> real 0m0.139s (https)
>>
>> On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote:
>>
>>> Hello!
>>>
>>> On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote:
>>>
>>> > Максим, спасибо за ответ!
>>> >
>>> > Сертификат действительно от LetsEncrypt,
>>> > отключение ssl_dhparam не помогло, на подобном сервере тоже с
>>> LetsEncrypt
>>> > тем же curl:
>>> > time_connect: 0.010
>>>
>>> Время time_connect - это время установления TCP-соединения, и в
>>> контексте исходного вопроса не интересно совершенно, в обоих
>>> приведённых в исходном письме примерах оно просто 0. Сравнивать
>>> имеет смысл time_total.
>>>
>>> > Подскажите куда можно еще глянуть?
>>> > Могу прислать debug или strace или что еще...
>>>
>>> Для начала - как уже было предложено, глянуть в сертификат
>>> ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть,
>>> какой алгоритм используется и сколько бит ключ. Если RSA и больше
>>> 2048 бит - поменять на 2048 бит или ECDSA.
>>>
>>> Если не поможет - имеет смысл снять дамп трафика с помощью
>>> tcpdump'а и посмотреть, где именно тратится время. Возможно,
>>> из-за чего-то вылезают сетевые проблемы, или проблема вообще на
>>> стороне клиента.
>>>
>>> --
>>> Maxim Dounin
>>> http://mdounin.ru/
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> --
>> Yours sincerely,
>> Vladimir Getmanshchuk
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL lags
Очень похоже это какой-то глюк curl(запускаю с той же машины),
я тут случайно сделал time wget https://server/object, и вот что получил:
WGET
real 0m0.004s (http)
real 0m0.012s (https)
CURL
real 0m0.012s (http)
real 0m0.139s (https)
On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote:
> Hello!
>
> On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote:
>
> > Максим, спасибо за ответ!
> >
> > Сертификат действительно от LetsEncrypt,
> > отключение ssl_dhparam не помогло, на подобном сервере тоже с LetsEncrypt
> > тем же curl:
> > time_connect: 0.010
>
> Время time_connect - это время установления TCP-соединения, и в
> контексте исходного вопроса не интересно совершенно, в обоих
> приведённых в исходном письме примерах оно просто 0. Сравнивать
> имеет смысл time_total.
>
> > Подскажите куда можно еще глянуть?
> > Могу прислать debug или strace или что еще...
>
> Для начала - как уже было предложено, глянуть в сертификат
> ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть,
> какой алгоритм используется и сколько бит ключ. Если RSA и больше
> 2048 бит - поменять на 2048 бит или ECDSA.
>
> Если не поможет - имеет смысл снять дамп трафика с помощью
> tcpdump'а и посмотреть, где именно тратится время. Возможно,
> из-за чего-то вылезают сетевые проблемы, или проблема вообще на
> стороне клиента.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL lags
Максим, спасибо за ответ!
Сертификат действительно от LetsEncrypt,
отключение ssl_dhparam не помогло, на подобном сервере тоже с LetsEncrypt
тем же curl:
time_connect: 0.010
Подскажите куда можно еще глянуть?
Могу прислать debug или strace или что еще...
On Wed, Nov 28, 2018 at 7:07 PM Maxim Dounin wrote:
> Hello!
>
> On Wed, Nov 28, 2018 at 06:20:12PM +0200, Vladimir Getmanshchuk wrote:
>
> > Странная ситуация с SSL - жуткий лаг на отдаче:
> >
> >
> > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X
> > GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null
> >
> > time_connect: 0.000
> >
> > time_total: 0.001
> >
> >
> > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X
> > GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o
> > /dev/null
> >
> > time_connect: 0.000
> >
> > time_total: *0.106*
>
> В SSL есть операция SSL handshake, и в зависимости от используемых
> шифров и сертификатов - она может занимать как просто много
> времени, так и очень много времени. (Ну и поскольку curl между
> запусками не может сохранять ранее установленную сессию - каждый
> запуск будет требовать полного handshake'а.)
>
> В частности, если вдруг используется обмен ключами с помощью
> алгоритма Диффи-Хеллмана - будет тормозить. Особенно если задать
> параметры где-нибудь на 4096 бит. Смотрите внимательно, что
> именно за шифры у вас используются, и если DHE - то что именно у
> вас лежит в ssl_dhparam. Ну или просто уберите ssl_dhparam из
> конфига - по умолчанию nginx просто не будет использовать DHE.
>
> Кроме того, будет тормозить, если используются RSA-сертификаты
> больше 2048 бит. Смотрите, что за сертификат используется.
> RSA-сертификаты на 4096 бит - зачастую по умолчанию прилетают из
> модных и молодёжных инструментов получения сертификатов от
> LetsEncrypt, но малопригодны для работы web-сервера.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
SSL lags
Странная ситуация с SSL - жуткий лаг на отдаче:
# curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X
GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null
time_connect: 0.000
time_total: 0.001
# curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X
GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o
/dev/null
time_connect: 0.000
time_total: *0.106*
# nginx -V
nginx version: nginx/1.14.1
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-compat --with-file-aio --with-threads --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module
--with-http_sub_module --with-http_v2_module --with-mail
--with-mail_ssl_module --with-stream --with-stream_realip_module
--with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g
-O2 -fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'
# cat /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_ciphers
'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:1024m;
ssl_stapling on;
ssl_stapling_verify on;
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как заставить Nginx отдавать error 521?
так 523 или 521?
я бы сделал
location @return52x {
return 521;
}
а потом как то туда передавать управления.. не знаю как..
2017-12-15 16:47 GMT+02:00 Ilya Evseev :
> Есть Nginx-frontend, он может вернуть Error 502 "Bad Gateway", если backend
> недоступен.
> Есть Nginx-backend, он тоже может вернуть Error 502.
>
> Как научить Nginx-frontend возвращать в случае недоступности backend'a не
> 502, а 523 "Origin is unreachable"?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,277785,277785#msg-277785
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Массированный rewrite или map ?
На бэкенде дорого, это форки и tcp оверхед, плюс наверно нагрузка на базу..
Я бы оставил map
вт, 30 трав. 2017 о 18:15 Konstantin Tokarev пише:
>
>
> 30.05.2017, 17:53, "Dee Dee" :
> > Добрый день всем.
> >
> > У меня возникла проблема на, казалось бы, простой задаче. У меня есть
> > порядка 300 штук редиректов в разделе блог вида:
> >
> > /blog?page=post&blog=blog_EN&id=298
> > /blog/topic1-theme-for-russian-speakers/
> > /blog?page=post&blog=blog_RU&id=300 /blog/webinar-new-staff/
> >
> > Как я понимаю, тут location это "blog" а далее пошли уже $args.
> > У меня получилось сделать это через map вида:
> >
> > map $args $link {
> > "blog?page=post&blog=blog_EN&id=300" "/blog/webinar-new-staff/";
> >
> > default "/blog/";
> > }
> >
> > и
> >
> > if ($args) {
> > return 301 $scheme://$host$link;
> > }
> >
> > Всё работает. Но map из трёхсот записей кажется мне громоздким.
> > Есть ли какие-либо варианты решения задачи, которые более элегантны, чем
> мой
> > ?
>
> В бэкэнде это делать
>
> >
> > Заранее большое спасибо!
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,274512,274512#msg-274512
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Regards,
> Konstantin
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование HTTPS + авторизация на бэкэенде по ключам
Авторизируйте клиента на фронте и просто передавайте переменные удачной/не
удачной авторизации на бэк, а там уже или 403 или "здрасьте заходите",
опшинал только верификацию настройте..
пн, 29 трав. 2017 о 17:43 RomkaV пише:
> Доброго времени суток!
> На фронтэнде установление сертификат компании, на бэкэнде организована
> авторизация клиентов по ключам. Есть задача: надо сделать локейшн на
> фронтэнде, который проксируется на бэкэнд, опять же надо, чтоб клиентский
> сертификат попал на бэкенд. На текущий момент зашел в тупик - сертификат
> клиента не попадает на бэкэнд через фронтэнд.
> Возможно ли такое реализовать?
>
> # Frontend
> server {
> listen 127.0.0.1:443 ssl default_server;
>
> ssl on;
> ssl_certificate /etc/nginx/ssl/server.crt;
> ssl_certificate_key /etc/nginx/ssl/server.key;
> ssl_client_certificate /etc/nginx/ssl/ca.crt;
> ssl_crl /etc/nginx/ssl/revoked/crl.pem;
> ssl_verify_client on;
>
> root /var/www/;
> index index.html index.htm ;
>
> }
>
> #Backend
> server {
> listen 127.0.0.1:8443;
>
> ssl on;
> ssl_certificate /etc/nginx/company_ssl/ssl.company.com.crt;
> ssl_certificate_key /etc/nginx/company_ssl/ssl.company.com.key;
>
> root /var/www2/;
>
>
> location / {
> proxy_pass https://127.0.0.1:443;
> proxy_set_header X-SSL-CLIENT-CERT $ssl_client_cert;
> proxy_set_header X-SSL-ClIENT-S-DN $ssl_client_s_dn;
> proxy_set_header X-CLIENT-VERIFY $ssl_client_verify;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto https;
> proxy_redirect off;
> }
> }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,274494,274494#msg-274494
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.12.0
Добрый день!
$variable_name - выдуманная конечно, реально $http_request_id и $request_id
2017-05-15 18:21 GMT+03:00 Maxim Dounin :
> Hello!
>
> On Sun, May 14, 2017 at 10:38:13PM +0300, Vladimir Getmanshchuk wrote:
>
> > Добрый вечер!
> >
> > После обновления на 1.12 в конфиге:
> > map $http_variable_name $variable_name {
> > ...
> > }
> >
> > ругается:
> > nginx: [emerg] the duplicate "variable_name" variable
>
> Судя по сообщению, вы пытаетесь переопределить встроенную
> переменную.
>
> В nginx'е нет переменной с именем $variable_name, так что если
> данное имя переменной настоящее - то посмотрите на список
> используемых сторонних модулей, возможно проблема там.
>
> Или же нужен полный (минимальный) конфиг, на котором
> воспроизводится проблема.
>
> --
> Maxim Dounin
> http://nginx.org/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.12.0
Добрый вечер!
После обновления на 1.12 в конфиге:
map $http_variable_name $variable_name {
...
}
ругается:
nginx: [emerg] the duplicate "variable_name" variable
debian jessie
2017-04-12 18:19 GMT+03:00 Maxim Dounin :
> Изменения в nginx 1.12.0
> 12.04.2017
>
> *) Стабильная ветка 1.12.x.
>
>
> --
> Maxim Dounin
> http://nginx.org/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_set_header и наследие
Hi В случае конкретно заголовка Host - nginx испольузет первое из > полученных значений. Это поведение, впрочем, историческое, и > стоит подумать о том, чтобы возвращать в подобных случаях 400, т.к. > синтаксис заголовка Host нескольких значений не допускает, и > свежий RFC 7230 явно требует именно 400 в случае нескольких > заголовков Host. > > Может следует делать ресет в proxy_set_header для хедера Host, что бы избежать 400, когда несколько NGINX в каскаде? :) -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_set_header и наследие
Hi! 2017-03-23 19:00 GMT+02:00 Maxim Dounin : > Hello! > Спасибо за скорый и развернутый ответ. > Документация о таком поведение - явно говорит, > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header: > > : Директивы наследуются с предыдущего уровня при условии, что на > : данном уровне не описаны свои директивы proxy_set_header. > > Не стоит удивляться такому поведению. Вместо этого - стоит его > понять и пользоваться преимуществами. > Читал. > > > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за > > include), то получаешь два хедера в HTTP запросе(от чего некоторые > backends > > сходят с ума, когда видят два хедера Host(например). > > Почему не брать значение из последнего proxy_set_header? > > В HTTP вполне допустимо использование нескольких одинаковых > заголовков, более того - явно специфицировано, когда можно, а > когда - нельзя, и как трактовать. И во многих случаях это > используется. > > Было бы странно ограничивать людей в том, что они могут написать в > конфиге, причём совсем не так, как специфицирует используемый > протокол. > А какое из значений двух хедеров "Host" будет использовать NGINX для определения server_name? > > > Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном > > тоже?) локейшене, а использовать наследие. > > Не пишите, кто же вас заставляет. > > В случае правильно и грамотно написанной конфигурации - обычно > хватает одного набора директив proxy_set_header на уровне http, > возможно - с отдельными вкраплениями "специальных" наборов. > Так и есть, но у меня меняется хедер Host на некоторых locations, что-бы отправить "сквозной" запрос на нужный мне микросервис внутри бэкэнда, без использования "прослойки".. > Если очень нужно вносить локальные изменения в конкретных > location'ах - можно использовать директиву include с неким базовым > набором, дополняя его по необходимости. Но если вы регулярно > сталкиваетесь с подобной проблемой - скорее всего вы что-то > делаете не так. > Так и решил, но выглядет не очень кошерно... -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
proxy_set_header и наследие
Доброе время суток! С этим proxy_set_header какой-то АД: 1) Почему proxy_set_header дикректива уровнем ниже перетирает ВСЕ proxy_set_header уровнем выше, а не только тот хедер который ресетишь? 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за include), то получаешь два хедера в HTTP запросе(от чего некоторые backends сходят с ума, когда видят два хедера Host(например). Почему не брать значение из последнего proxy_set_header? Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном тоже?) локейшене, а использовать наследие. Спасибо за внимание, извините за непонимание :) -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx cache issue
Отбой :)
On Sun, Nov 6, 2016 at 7:27 PM, Vladimir Getmanshchuk
wrote:
> Добрый вечер, тут какой то ад, не работает кеш, уже более часа потратил:
>
> *# *nginx -V
>
> nginx version: nginx/1.10.0 (Ubuntu)
>
> built with OpenSSL 1.0.2g 1 Mar 2016
>
> TLS SNI support enabled
>
> configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2'
> --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro
> -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
> --http-log-path=/var/log/nginx/access.log
> --error-log-path=/var/log/nginx/error.log
> --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
> --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> --http-proxy-temp-path=/var/lib/nginx/proxy
> --http-scgi-temp-path=/var/lib/nginx/scgi
> --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
> --with-ipv6 --with-http_ssl_module --with-http_stub_status_module
> --with-http_realip_module --with-http_auth_request_module
> --with-http_addition_module --with-http_dav_module --with-http_geoip_module
> --with-http_gunzip_module --with-http_gzip_static_module
> --with-http_image_filter_module --with-http_v2_module
> --with-http_sub_module --with-http_xslt_module --with-stream
> --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads
>
>
> *# *grep catalog /etc/nginx/conf.d/proxy.conf
>
> proxy_cache_path /dev/shm/nginx_cache_*catalog*_microservice levels=1:2
> keys_zone=*catalog*_microservice:500m inactive=30d max_size=1G;
>
>
> из vhost:
>
>
> location /v2/categories/parents/ {
>
> access_log /var/log/nginx/access_monitoring.log monitoring
> buffer=16k;
>
> proxy_cache catalog_microservice;
>
> proxy_cache_key "$request_method$host$request_uri";
>
> proxy_ignore_headers "Cache-Control" "Expires";
>
> proxy_cache_valid 200 10m;
>
> proxy_pass http://app-backend;
>
> }
>
>
>
> *# *curl -XGET -I http://catalog.my.site/v2/categories/parents/1164?
> country_id=8
>
> HTTP/1.1 200 OK
>
> Server: nginx/1.10.0 (Ubuntu)
>
> Date: Sun, 06 Nov 2016 17:25:19 GMT
>
> Content-Type: application/json; charset=UTF-8
>
> Content-Length: 710
>
> Connection: keep-alive
>
> Access-Control-Allow-Origin: *
>
> Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
>
> Access-Control-Allow-Headers: Content-Type, Authorization
>
> *# *find /dev/shm/nginx_cache_catalog_microservice/ -type f | wc -l
>
> 0
>
>
>
> --
> Yours sincerely,
> Vladimir Getmanshchuk
>
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx cache issue
Добрый вечер, тут какой то ад, не работает кеш, уже более часа потратил:
*# *nginx -V
nginx version: nginx/1.10.0 (Ubuntu)
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2'
--with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now'
--prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
--with-ipv6 --with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-http_auth_request_module
--with-http_addition_module --with-http_dav_module --with-http_geoip_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_image_filter_module --with-http_v2_module
--with-http_sub_module --with-http_xslt_module --with-stream
--with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads
*# *grep catalog /etc/nginx/conf.d/proxy.conf
proxy_cache_path /dev/shm/nginx_cache_*catalog*_microservice levels=1:2
keys_zone=*catalog*_microservice:500m inactive=30d max_size=1G;
из vhost:
location /v2/categories/parents/ {
access_log /var/log/nginx/access_monitoring.log monitoring
buffer=16k;
proxy_cache catalog_microservice;
proxy_cache_key "$request_method$host$request_uri";
proxy_ignore_headers "Cache-Control" "Expires";
proxy_cache_valid 200 10m;
proxy_pass http://app-backend;
}
*# *curl -XGET -I
http://catalog.my.site/v2/categories/parents/1164?country_id=8
HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sun, 06 Nov 2016 17:25:19 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 710
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
*# *find /dev/shm/nginx_cache_catalog_microservice/ -type f | wc -l
0
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
CVE-2015-0235 - GHOST
JFYI Here is a list of potential targets that we investigated (they all call *gethostbyname*, one way or another), but to the best of our knowledge, the buffer overflow cannot be triggered in any of them: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, *nginx*, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd. http://seclists.org/oss-sec/2015/q1/283 -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как настроить 301й редирект на nginx
как то так, если я не ошибся в регулярке:
location ~* shopby {
rewrite ^/(.*)/shopby/.*\.html$ /$1.html permanent;
}
но уверен есть способы поизящнее...
On Sun, Dec 21, 2014 at 3:20 PM, Gavich wrote:
> Нужно сделать редирект с страниц вида
> /цифры_буквы_дефис_1/shopby/цифры_буквы_дефис_2.html
> на /цифры_буквы_дефис_1.html.
> Например с
> /196-vse-dlja-zhenschin/shopby/sisley-rimowa-ianis_chamalidy.html
> на 196-vse-dlja-zhenschin.html
> Как изменить конфиг сайта?
>
> Сейчас настройки сайта такие:
>
> server {
> server_name moda-spb.ru www.moda-spb.ru;
> listen 176.9.36.66;
> root /var/www/moda-spb.ru;
> index index.php;
>
> location / {
> index index.html index.php;
> try_files $uri $uri/ @handler;
> expires 30d;
> }
>
> location ^~
> /(app|includes|lib|media/downloadable|pkginfo|report/config.xml|var)/ {
> internal; }
> location /var/export/ { internal; }
> location /. { return 404; }
> location @handler { rewrite / /index.php; }
> location ~* .php/ { rewrite ^(.*.php)/ $1 last; }
> location ~* .php$ {
> if (!-e $request_filename) { rewrite / /index.php last; }
> expires off;
> fastcgi_pass php-fpm;
> fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
> fastcgi_param MAGE_RUN_CODE default;
> fastcgi_param MAGE_RUN_TYPE store;
> include fastcgi_params;
> }
> }
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,255708,255708#msg-255708
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ошибка 400 request header or cookie too large
Добрый день! Все просто: http://wiki.nginx.org/HttpCoreModule#large_client_header_buffers 2013/9/19 Дмитрий Бехтерев > Добрый день! > Ошибку 400 Bad request (request header or cookie too large) выдает > nginx, стоящий на фронт-енде (на бэк-енде апач). Ошибка плавающая, может > быть при посещениях разных ссылок с разных браузеров. > Жалуются клиенты региональные. В Москве ни у кого, в т.ч. у себя отловить > не смог. > Подскажите, куда копать. Можно ли как-то включить лог таких ошибок. > Спасибо. > > __**_ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru<http://mailman.nginx.org/mailman/listinfo/nginx-ru> -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: true 414 status code
Спасибо починилось.
Пусть тут полежит:
--- src/http/ngx_http_header_filter_module.c.orig 2013-05-13
10:43:28.0 +
+++ src/http/ngx_http_header_filter_module.c 2013-09-05 14:37:15.011369647
+
@@ -92,10 +92,7 @@
ngx_string("411 Length Required"),
ngx_string("412 Precondition Failed"),
ngx_string("413 Request Entity Too Large"),
-ngx_null_string, /* "414 Request-URI Too Large", but we never send it
- * because we treat such requests as the HTTP/0.9
- * requests and send only a body without a header
- */
+ngx_string("414 Request-URI Too Large"),
ngx_string("415 Unsupported Media Type"),
ngx_string("416 Requested Range Not Satisfiable"),
@@ -270,6 +267,12 @@
len += NGX_INT_T_LEN;
status_line = NULL;
}
+
+if (status_line && status_line->len == 0) {
+status = r->headers_out.status;
+len += NGX_INT_T_LEN;
+status_line = NULL;
+}
}
clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
On Wed, Sep 4, 2013 at 1:51 PM, Валентин Бартенев wrote:
> On Wednesday 04 September 2013 13:54:18 Vladimir Getmanshchuk wrote:
> > Даже идиотизм типа:
> >
> > error_page 414 =414 @414;
> >
> > location @414 {
> > return 414;
> > }
> > не дал результат - получаю 200
> >
> > 2013/09/04 09:40:10 [info] 5564#0: *45 client sent too long URI while
> > reading client request line, client: 123.123.123.123, server:
> > host.example.com, request: "GET
> >
> /file.php?qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasd
> >
> fghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiop
> >
> asdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyu
> >
> iopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwer
> >
> tyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq
> >
> wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvb
> >
> nmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzx
> >
> cvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjk
> >
> lzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg
> >
> hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopas
> >
> dfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuio
> >
> pasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwerty
> >
> uiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwe
> >
> rtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnm
> >
> qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv
> >
> bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklz
> >
> xcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghj
> >
> klzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdf
> >
> ghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopa
> >
> sdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui
> >
> opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwert
> >
> yuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw
> >
> ertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbn
> >
> mqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxc
> > vbnmqwertyuiopasdfghjklzxcvbnmqwer 2013/09/04 09:40:10 [debug] 5564#0:
> *45
> > http finalize request: 414, "?" a:1, c:1
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 event timer del: 15:
> 1378287669763
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 test location: "@414"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 using location: @414 "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 rewrite phase: 3
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
> > a:1, c:2
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http set discard body
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 xslt filter header
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 HTTP/1.1
> > Server: nginx/1.2.9
> > Date: Wed, 04 Sep 2013 09:40:10 GMT
>
Re: true 414 status code
Даже идиотизм типа:
error_page 414 =414 @414;
location @414 {
return 414;
}
не дал результат - получаю 200
2013/09/04 09:40:10 [info] 5564#0: *45 client sent too long URI while
reading client request line, client: 123.123.123.123, server:
host.example.com, request: "GET
/file.php?qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwer
2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
a:1, c:1
2013/09/04 09:40:10 [debug] 5564#0: *45 event timer del: 15: 1378287669763
2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 test location: "@414"
2013/09/04 09:40:10 [debug] 5564#0: *45 using location: @414 "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 rewrite phase: 3
2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
a:1, c:2
2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 http set discard body
2013/09/04 09:40:10 [debug] 5564#0: *45 xslt filter header
2013/09/04 09:40:10 [debug] 5564#0: *45 HTTP/1.1
Server: nginx/1.2.9
Date: Wed, 04 Sep 2013 09:40:10 GMT
Content-Type: text/html
Content-Length: 192
Connection: close
2013/9/3 Vladimir Getmanshchuk
> Все одно получаю 200й код.
>
>
> 2013/9/2 Валентин Бартенев
>
>> On Monday 02 September 2013 16:58:05 Vladimir Getmanshchuk wrote:
>> > Здорово!
>> >
>> > Но не повлияет ли это на производительность?
>> >
>> > Спасибо!
>> >
>>
>> Не повлияет.
>>
>> --
>> Валентин Бартенев
>> http://nginx.org/en/donation.html
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> Yours sincerely,
> Vladimir Getmanshchuk
>
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: true 414 status code
Все одно получаю 200й код. 2013/9/2 Валентин Бартенев > On Monday 02 September 2013 16:58:05 Vladimir Getmanshchuk wrote: > > Здорово! > > > > Но не повлияет ли это на производительность? > > > > Спасибо! > > > > Не повлияет. > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: true 414 status code
Здорово! Но не повлияет ли это на производительность? Спасибо! 2013/9/2 Gena Makhomed > On 02.09.2013 7:00, Валентин Бартенев wrote: > > > JFYI, > > http://hg.nginx.org/nginx/rev/**62be77b0608f<http://hg.nginx.org/nginx/rev/62be77b0608f> > > спасибо, теперь nginx стал еще лучше и удобнее. > > -- > Best regards, > Gena > > > __**_ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru<http://mailman.nginx.org/mailman/listinfo/nginx-ru> > -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
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 Валентин Бартенев > On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: > > Здравствуйте! > > > > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 > > status code, на запросы, размер которых, превышает large_client_header_ > > buffers? > > > > Постоянно получаю 200 http status code и нижеприведенное в body: > > > > > > 414 Request-URI Too Large > > > > 414 Request-URI Too Large > > nginx/1.2.9 > > > > > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой. > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
true 414 status code
Здравствуйте! Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 status code, на запросы, размер которых, превышает large_client_header_ buffers? Постоянно получаю 200 http status code и нижеприведенное в body: 414 Request-URI Too Large 414 Request-URI Too Large nginx/1.2.9 -- Yours sincerely, Vladimir Getmanshchuk ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
limit request and real ip
Добрый день!
1. Допустим дано:
http {
...
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
...
}
значит ли это что у меня в $binary_remote_addr будет реальный ip клиента?
или все же ip будет из сети 10.0.0.0/8 ?
2. Если все же второе, то верно ли что мне следует описывать зону как
описанно ниже?
http {
...
limit_req_zone $http_x_forwarded_for zone=one:10m rate=1r/s;
...
}
Спасибо!
--
Yours sincerely,
Vladimir Getmanshchuk
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
