Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live

systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

$
0
0
Здравствуйте, All!

nginx установлен из официального репозитория nginx.org, CentOS 7.4

В логах вот такое наблюдается при перезапуске nginx 1.13.6:

systemd: Starting nginx - high performance web server...
nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful
systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
systemd: Started nginx - high performance web server.

И вот такое при запуске nginx 1.13.7:

systemd: Starting nginx - high performance web server...
systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
systemd: Started nginx - high performance web server.

Как это можно победить, чтобы в логах такого не было?

Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804
И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993

Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл?

Обе эти ошибки возникают в systemd функции service_load_pid_file()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L815
Когда systemd не может прочитать pid-файл.

Насколько я понял из комментариев в функции service_enter_start()
https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909

/* For forking services we wait until the start
* process exited. */

И в функции service_sigchld_event():
https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959

/* Forking services may occasionally move to a new PID.
* As long as they update the PID file before exiting the old
* PID, they're fine. */

Systemd считает что сервис запустился
после того как start process exited ?

А у nginx получается так, что start process exited,
а pid файл еще не создан и это создает проблемы systemd?

Можно ли как-то исправить поведение nginx,
чтобы systemd не флудил в логи сообщениями об ошибках?

--
Best regards,
Gena

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

Asynchronous Handler & Callbacks

$
0
0
I'm writing my own Module and Handler for nginx, but I can't figure out how to do asynchronous work.


From my handler, I'm calling an existing library, that'll run a callback on a thread of its own when it is done.

I can't figure out how to switch back to the nginx event loop thread.


It seems like it's ok for me to run

r->blocked++;
return NGX_AGAIN;

inside my callback handler the first time it's called, but once the "external" callback runs, it'd need to tell nginx to run my handler again. I'm assuming that I'd do that my posting an event to the request's event loop and then call

ngx_http_core_run_phases(r)

on the request. But I'm a bit lost as to whether that's the right approach.

Thanks in advance.

/Daniel

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

Re: nginx-1.13.7

$
0
0
А можете прокомментировать чуть подробнее про?
>Исправление: в переменной $upstream_status.
>Исправление: в модуле ngx_http_fastcgi_module.

Благодарю!

21 ноября 2017 г., 19:23 пользователь Maxim Dounin <mdounin@mdounin.ru>
написал:

> Hello!
>
> On Tue, Nov 21, 2017 at 12:18:41PM -0500, vitcool wrote:
>
> > Maxim Dounin Wrote:
> > -------------------------------------------------------
> > > Изменения в nginx 1.13.7
> > > 21.11.2017
> > > *) Исправление: nginx возвращал ошибку 500, если в директиве
> > > xslt_stylesheet были заданы параметры без использования
> > > переменных.
> >
> >
> > Я прошу прощения, а nginx умеет делать xsl трансформацию?
>
> Да, начиная с 0.7.8.
> Подробнее тут:
>
> http://nginx.org/ru/docs/http/ngx_http_xslt_module.html
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> 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

Re: nginx-1.13.7

$
0
0
Hello!

On Wed, Nov 22, 2017 at 12:33:59AM +0200, Sargas wrote:

> А можете прокомментировать чуть подробнее про?
> >Исправление: в переменной $upstream_status.

Если в конфигурации было сказано "proxy_next_upstream http_503
http_504", то в переменной $upstream_status вместо статуса 503 /
504 отображался статус 502. Подробнее тут:

http://hg.nginx.org/nginx/rev/882ad033d43c

> >Исправление: в модуле ngx_http_fastcgi_module.

Не сохранялась позиция парсинга заголовков FastCGI records, и если
вдруг при получении заголовков ответа какой-то record header
приходил частично (что на практике, судя по всему, не встречается,
но теоретически возможно) - то парсинг ломался, и возникала
ошибка. Подробнее тут:

http://hg.nginx.org/nginx/rev/3b635e8fd499

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Fwd: [ module ] Add http upstream keep alive timeout parameter

$
0
0
Hi,

Is there any place to view the status of current proposed patches? I'm not
sure if this patch had been accepted, still waiting or rejected?

In order to avoid errors in production, I'm running the patched version
now. But I think it would be better to run the official one, and also I can
introduce this solution for 'Connection reset by peer errors' to other
teams.

On Tue, Nov 14, 2017 at 2:03 PM, Wei Xu <weixu365@gmail.com> wrote:

> Hi,
>
> Really nice, much simpler than my patch. It's great to have a default
> timeout value. thanks for you time.
>
>
>
> On Tue, Nov 14, 2017 at 6:49 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
>> Hello!
>>
>> On Sun, Nov 12, 2017 at 11:25:20PM +1100, Wei Xu wrote:
>>
>> > We are running Nginx and upstream on the same machine using docker, so
>> > there's no firewall.
>>
>> Note that this isn't usually true. Docker uses iptables
>> implicitly, and unless you specifically checked your iptables
>> configuration - likely you are using firewall.
>>
>> > I did a test locally and captured the network packages.
>> >
>> > For the normal requests, upstream send a [FIN, ACK] to nginx after
>> > keep-alive timeout (500 ms), and nginx also send a [FIN, ACK] back, then
>> > upstream send a [ACK] to close the connection completely.
>>
>> [...]
>>
>> > For more detailed description of the test process, you can reference my
>> > post at:
>> > https://theantway.com/2017/11/analyze-connection-reset-error
>> -in-nginx-upstream-with-keep-alive-enabled/
>>
>> The test demonstrates that it is indeed possible to trigger the
>> problem in question. Unfortunately, it doesn't provide any proof
>> that what you observed in production is the same issue though.
>>
>> While it is more or less clear that the race condition in question
>> is real, it seems to be very unlikely with typical workloads. And
>> even when triggered, in most cases nginx handles this good enough,
>> re-trying the request per proxy_next_upstream.
>>
>> Nevertheless, thank you for detailed testing. A simple test case
>> that reliably demonstrates the race is appreciated, and I was able
>> to reduce it to your client script and nginx with the following
>> trivial configuration:
>>
>> upstream u {
>> server 127.0.0.1:8082;
>> keepalive 10;
>> }
>>
>> server {
>> listen 8080;
>>
>> location / {
>> proxy_pass http://u;
>> proxy_http_version 1.1;
>> proxy_set_header Connection "";
>> }
>> }
>>
>> server {
>> listen 8082;
>>
>> keepalive_timeout 500ms;
>>
>> location / {
>> return 200 ok\n;
>> }
>> }
>>
>> > To Fix the issue, I tried to add a timeout for keep-alived upstream, and
>> > you can check the patch at:
>> > https://github.com/weixu365/nginx/blob/docker-1.13.6/docker/
>> stretch/patches/01-http-upstream-keepalive-timeout.patch
>> >
>> > The patch is for my current testing, and I can create a different
>> format if
>> > you need.
>>
>> The patch looks good enough for testing, though there are various
>> minor issues - notably testing timeout for NGX_CONF_UNSET_MSEC at
>> runtime, using wrong type for timeout during parsing (time_t
>> instead of ngx_msec_t).
>>
>> Also I tend to think that using a separate keepalive_timeout
>> directive should be easier, and we probably want to introduce some
>> default value for it.
>>
>> Please take a look if the following patch works for you:
>>
>> # HG changeset patch
>> # User Maxim Dounin <mdounin@mdounin.ru>
>> # Date 1510601341 -10800
>> # Mon Nov 13 22:29:01 2017 +0300
>> # Node ID 9ba0a577601b7c1b714eb088bc0b0d21c6354699
>> # Parent 6f592a42570898e1539d2e0b86017f32bbf665c8
>> Upstream keepalive: keepalive_timeout directive.
>>
>> The directive configures maximum time a connection can be kept in the
>> cache. By configuring a time which is smaller than the corresponding
>> timeout on the backend side one can avoid the race between closing
>> a connection by the backend and nginx trying to use the same connection
>> to send a request at the same time.
>>
>> diff --git a/src/http/modules/ngx_http_upstream_keepalive_module.c
>> b/src/http/modules/ngx_http_upstream_keepalive_module.c
>> --- a/src/http/modules/ngx_http_upstream_keepalive_module.c
>> +++ b/src/http/modules/ngx_http_upstream_keepalive_module.c
>> @@ -12,6 +12,7 @@
>>
>> typedef struct {
>> ngx_uint_t max_cached;
>> + ngx_msec_t timeout;
>>
>> ngx_queue_t cache;
>> ngx_queue_t free;
>> @@ -84,6 +85,13 @@ static ngx_command_t ngx_http_upstream_
>> 0,
>> NULL },
>>
>> + { ngx_string("keepalive_timeout"),
>> + NGX_HTTP_UPS_CONF|NGX_CONF_TAKE1,
>> + ngx_conf_set_msec_slot,
>> + NGX_HTTP_SRV_CONF_OFFSET,
>> + offsetof(ngx_http_upstream_keepalive_srv_conf_t, timeout),
>> + NULL },
>> +
>> ngx_null_command
>> };
>>
>> @@ -141,6 +149,8 @@ ngx_http_upstream_init_keepalive(ngx_con
>>
>> us->peer.init = ngx_http_upstream_init_keepalive_peer;
>>
>> + ngx_conf_init_msec_value(kcf->timeout, 60000);
>> +
>> /* allocate cache items and add to free queue */
>>
>> cached = ngx_pcalloc(cf->pool,
>> @@ -261,6 +271,10 @@ found:
>> c->write->log = pc->log;
>> c->pool->log = pc->log;
>>
>> + if (c->read->timer_set) {
>> + ngx_del_timer(c->read);
>> + }
>> +
>> pc->connection = c;
>> pc->cached = 1;
>>
>> @@ -339,9 +353,8 @@ ngx_http_upstream_free_keepalive_peer(ng
>>
>> pc->connection = NULL;
>>
>> - if (c->read->timer_set) {
>> - ngx_del_timer(c->read);
>> - }
>> + ngx_add_timer(c->read, kp->conf->timeout);
>> +
>> if (c->write->timer_set) {
>> ngx_del_timer(c->write);
>> }
>> @@ -392,7 +405,7 @@ ngx_http_upstream_keepalive_close_handle
>>
>> c = ev->data;
>>
>> - if (c->close) {
>> + if (c->close || c->read->timedout) {
>> goto close;
>> }
>>
>> @@ -485,6 +498,8 @@ ngx_http_upstream_keepalive_create_conf(
>> * conf->max_cached = 0;
>> */
>>
>> + conf->timeout = NGX_CONF_UNSET_MSEC;
>> +
>> return conf;
>> }
>>
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Set Expires Header only if upstream has not already set an Expires

$
0
0
Hello,
I would like to add an Expires Header only to upstream content that has
not already set an Expires header. Is there an easy way to do that with
nginx?

I thought about trying to add a header_filter_by_lua checking the
Expires header and set the necessary value if not already set. Is there
an easier way to do the same?

Cheers,
Thomas
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: nginx repos Ubuntu 17.10 artful

$
0
0
On 10/11/2017 14:13, Konstantin Pavlov wrote:
> Добрый день,
>
> On 10/11/2017 10:14, Vadim Lazovskiy wrote:
>> Здравствуйте.
>>
>> Не могли бы вы приготовить пакеты для Ubuntu 17.10?
>>
>> Спасибо!
>
> Будет со следующим mainline релизом.

Пакеты для 17.10 выложены для 1.13.7.

--
Konstantin Pavlov
www.nginx.com
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf

$
0
0
On 10/11/2017 17:37, Konstantin Pavlov wrote:
>> В юнит-файле CentOS 7 эта строчка
>>
>> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
>>
>> выглядит совершенно лишней и не нужной, она только создает проблемы.
>>
>> Может быть имеет смысл вообще убрать строку
>>
>> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
>>
>> из юнит-файла? Хуже от этого ведь не станет, только лучше.
>>
>> Или я ошибаюсь и в этой строчке есть какой-смысл? Какой?
> Не ошибаетесь.

Убрал, начиная с 1.13.7: http://hg.nginx.org/pkg-oss/rev/3074685a0155

--
Konstantin Pavlov
www.nginx.com
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx repos Ubuntu 17.10 artful

$
0
0
Большое спасибо!

22 ноября 2017 г., 13:01 пользователь Konstantin Pavlov <thresh@nginx.com>
написал:

> On 10/11/2017 14:13, Konstantin Pavlov wrote:
> > Добрый день,
> >
> > On 10/11/2017 10:14, Vadim Lazovskiy wrote:
> >> Здравствуйте.
> >>
> >> Не могли бы вы приготовить пакеты для Ubuntu 17.10?
> >>
> >> Спасибо!
> >
> > Будет со следующим mainline релизом.
>
> Пакеты для 17.10 выложены для 1.13.7.
>
> --
> Konstantin Pavlov
> www.nginx.com
>



--
WBR,
Vadim Lazovskiy
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx seems to treat %3F as "?"

$
0
0
Hello,

I have following redirection rule defined:

location ~ "^/(.*)\.html[^\?]+" {
return 301 /$1.html;
}

so that everything besides "?" after an URL gets truncated:
like
example.com/test.html%D1%80%D0%BE%D1%80%D0%BB -> example.com/test.html

however it doesn't work when "?" is url encoded into %3F. I would like
example.com/test.html%3F to redirect to example.com/test.html

Is it possible somehow?

Thank you!

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

[njs] Fixed building by GCC with -O3.

$
0
0
details: http://hg.nginx.org/njs/rev/22cc52416e84
branches:
changeset: 433:22cc52416e84
user: Dmitry Volyntsev <xeioex@nginx.com>
date: Wed Nov 22 18:55:57 2017 +0300
description:
Fixed building by GCC with -O3.

diffstat:

njs/njs_fs.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diffs (21 lines):

diff -r 5eb2620a9bec -r 22cc52416e84 njs/njs_fs.c
--- a/njs/njs_fs.c Mon Nov 20 20:08:56 2017 +0300
+++ b/njs/njs_fs.c Wed Nov 22 18:55:57 2017 +0300
@@ -566,6 +566,8 @@ static njs_ret_t njs_fs_write_file_inter
}

mode = NULL;
+ /* GCC complains about uninitialized flag.length. */
+ flag.length = 0;
flag.start = NULL;
encoding.length = 0;
encoding.start = NULL;
@@ -753,6 +755,8 @@ njs_fs_write_file_sync_internal(njs_vm_t
}

mode = NULL;
+ /* GCC complains about uninitialized flag.length. */
+ flag.length = 0;
flag.start = NULL;
encoding.length = 0;
encoding.start = NULL;
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Fwd: [ module ] Add http upstream keep alive timeout parameter

$
0
0
Hello!

On Wed, Nov 22, 2017 at 05:31:25PM +1100, Wei Xu wrote:

> Hi,
>
> Is there any place to view the status of current proposed patches? I'm not
> sure if this patch had been accepted, still waiting or rejected?
>
> In order to avoid errors in production, I'm running the patched version
> now. But I think it would be better to run the official one, and also I can
> introduce this solution for 'Connection reset by peer errors' to other
> teams.

The patch in question is sitting in my patch queue waiting for
further work - I consider introducing keepalive_requests at the
same time, and probably $upstream_connection and
$upstream_connection_requests variables.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[njs] Fixed unit tests for NetBSD 7.

$
0
0
details: http://hg.nginx.org/njs/rev/c69b48375b90
branches:
changeset: 434:c69b48375b90
user: Dmitry Volyntsev <xeioex@nginx.com>
date: Wed Nov 22 20:38:10 2017 +0300
description:
Fixed unit tests for NetBSD 7.

diffstat:

njs/test/njs_unit_test.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)

diffs (69 lines):

diff -r 22cc52416e84 -r c69b48375b90 njs/test/njs_unit_test.c
--- a/njs/test/njs_unit_test.c Wed Nov 22 18:55:57 2017 +0300
+++ b/njs/test/njs_unit_test.c Wed Nov 22 20:38:10 2017 +0300
@@ -538,8 +538,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("'0' ** 0.1"),
nxt_string("0") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("0 ** '-0.1'"),
nxt_string("Infinity") },
+#endif

{ nxt_string("(-0) ** 3"),
nxt_string("-0") },
@@ -550,8 +552,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("(-0) ** '-3'"),
nxt_string("-Infinity") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("'-0' ** -2"),
nxt_string("Infinity") },
+#endif

{ nxt_string("(-3) ** 0.1"),
nxt_string("NaN") },
@@ -604,8 +608,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("var a = '0'; a **= 0.1"),
nxt_string("0") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("var a = 0; a **= '-0.1'"),
nxt_string("Infinity") },
+#endif

{ nxt_string("var a = -0; a **= 3"),
nxt_string("-0") },
@@ -616,8 +622,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("var a = -0; a **= '-3'"),
nxt_string("-Infinity") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("var a = '-0'; a **= -2"),
nxt_string("Infinity") },
+#endif

{ nxt_string("var a = -3; a **= 0.1"),
nxt_string("NaN") },
@@ -7799,8 +7807,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("Math.pow('0', 0.1)"),
nxt_string("0") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("Math.pow(0, '-0.1')"),
nxt_string("Infinity") },
+#endif

{ nxt_string("Math.pow(-0, 3)"),
nxt_string("-0") },
@@ -7811,8 +7821,10 @@ static njs_unit_test_t njs_test[] =
{ nxt_string("Math.pow(-0, '-3')"),
nxt_string("-Infinity") },

+#ifndef __NetBSD__ /* NetBSD 7: pow(0, negative) == -Infinity. */
{ nxt_string("Math.pow('-0', -2)"),
nxt_string("Infinity") },
+#endif

{ nxt_string("Math.pow(-3, 0.1)"),
nxt_string("NaN") },
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

$
0
0
Hello!

On Tue, Nov 21, 2017 at 10:46:58PM +0200, Gena Makhomed wrote:

> Здравствуйте, All!
>
> nginx установлен из официального репозитория nginx.org, CentOS 7.4
>
> В логах вот такое наблюдается при перезапуске nginx 1.13.6:
>
> systemd: Starting nginx - high performance web server...
> nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful
> systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
> systemd: Started nginx - high performance web server.
>
> И вот такое при запуске nginx 1.13.7:
>
> systemd: Starting nginx - high performance web server...
> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> systemd: Started nginx - high performance web server.
>
> Как это можно победить, чтобы в логах такого не было?
>
> Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804
> И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993
>
> Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл?
>
> Обе эти ошибки возникают в systemd функции service_load_pid_file()
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L815
> Когда systemd не может прочитать pid-файл.
>
> Насколько я понял из комментариев в функции service_enter_start()
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909
>
> /* For forking services we wait until the start
> * process exited. */
>
> И в функции service_sigchld_event():
> https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959
>
> /* Forking services may occasionally move to a new PID.
> * As long as they update the PID file before exiting the old
> * PID, they're fine. */
>
> Systemd считает что сервис запустился
> после того как start process exited ?
>
> А у nginx получается так, что start process exited,
> а pid файл еще не создан и это создает проблемы systemd?
>
> Можно ли как-то исправить поведение nginx,
> чтобы systemd не флудил в логи сообщениями об ошибках?

С точки зрения абстрактного счастья для всех даром - наверное,
поведение systemd логично, и на момент выхода запущенного процесса
pid-файл должен уже существовать.

С точки зрения практики - паттерн "daemon(); write_pidfile();"
используется чуть менее, чем везде, вплоть до соответствующих
библиотечных функций. Так что инициатива выглядит, скажем так,
сомнительной.

Проще всего, IMHO, это было бы заткнуть на уровне systemd,
дожидаясь появления pid-файла при необходимости.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx reload issues

$
0
0
Hi,

I have a centos7 server as a reverse proxy. When I either make a change to an existing v.hosts file or create a new one and test the set up with "nginx -t", and it works, I trigger the changes with either "systemctl reload nginx" or "nginx -s reload". Unfortunately this seems to no longer reload the new config? If I actually restart the Nginx server itself ("systemctl restart nginx") it works but obviously this breaks current connections. There are no errors in the log files

Any ideas as to what may be causing the problem?


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

Re: nginx seems to treat %3F as "?"

$
0
0
On Wed, Nov 22, 2017 at 05:34:13PM +0200, ST wrote:

Hi there,

> I have following redirection rule defined:
>
> location ~ "^/(.*)\.html[^\?]+" {

That says: /anything.html followed by one-or-more things that are not ?.

Note that "location" works on the unencoded url version, and does not
include the ? that marks the query string, or anything after it.

> return 301 /$1.html;
> }
>
> so that everything besides "?" after an URL gets truncated:

No.

*everything* after .html gets removed in the 301 response, provided
that there is something immediately after .html that is not a ? (which
would be %3F in the original url, because ? is special).

> like
> example.com/test.html%D1%80%D0%BE%D1%80%D0%BB -> example.com/test.html

The thing immediately after .html is the unencoded version of %D1, which is
not ?, so the location matches and the rewrite happens.

> however it doesn't work when "?" is url encoded into %3F. I would like
> example.com/test.html%3F to redirect to example.com/test.html

Your location block explicitly excludes that case.

Why?

As in: I do not understand what the thing that you are trying to achieve
is. Can you explain it? Perhaps with examples of some things that should
be rewritten and some things that should not be?

At a guess, perhaps

location ~ ^/(.*)\.html. {

is what you want? Starts with /, includes .html, and is followed by anything.

That should match /a.htmlx and /a.html%3Fx, but not /a.html or /a.html?x=y

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Set Expires Header only if upstream has not already set an Expires

$
0
0
On Wed, Nov 22, 2017 at 10:41:49AM +0100, Thomas Glanzmann wrote:

Hi there,

> I would like to add an Expires Header only to upstream content that has
> not already set an Expires header. Is there an easy way to do that with
> nginx?

http://nginx.org/r/expires has an example of setting a value based on
$sent_http_content_type.

You can set a value based on $upstream_http_expires --

{ default off; "" 7d; }

in the appropriate "map" should set your Expires time to 7 days from now
if there is not an Expires: header from the upstream.

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: nginx seems to treat %3F as "?"

$
0
0
On Wed, 2017-11-22 at 22:11 +0000, Francis Daly wrote:
> On Wed, Nov 22, 2017 at 05:34:13PM +0200, ST wrote:
>
> Hi there,
>
> > I have following redirection rule defined:
> >
> > location ~ "^/(.*)\.html[^\?]+" {
>
> That says: /anything.html followed by one-or-more things that are not ?.
>
> Note that "location" works on the unencoded url version, and does not
> include the ? that marks the query string, or anything after it.
>
> > return 301 /$1.html;
> > }
> >
> > so that everything besides "?" after an URL gets truncated:
>
> No.
>
> *everything* after .html gets removed in the 301 response, provided
> that there is something immediately after .html that is not a ? (which
> would be %3F in the original url, because ? is special).
>
> > like
> > example.com/test.html%D1%80%D0%BE%D1%80%D0%BB -> example.com/test.html
>
> The thing immediately after .html is the unencoded version of %D1, which is
> not ?, so the location matches and the rewrite happens.
>
> > however it doesn't work when "?" is url encoded into %3F. I would like
> > example.com/test.html%3F to redirect to example.com/test.html
>
> Your location block explicitly excludes that case.
>
> Why?
>
> As in: I do not understand what the thing that you are trying to achieve
> is. Can you explain it? Perhaps with examples of some things that should
> be rewritten and some things that should not be?
>
> At a guess, perhaps
>
> location ~ ^/(.*)\.html. {
>
> is what you want? Starts with /, includes .html, and is followed by anything.
>
> That should match /a.htmlx and /a.html%3Fx, but not /a.html or /a.html?x=y

Thank you very much! That was exactly what I needed!

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

Проблемы при написании модуля-замены TLS для NGINX (NoiseSocket)

$
0
0
Приветствую, меня зовут Алексей. Я работаю в компании VirgilSecurity и
являюсь разработчиком протокола NoiseSocket (noisesocket.com).
Так же наша компания занимается разработкой модуля для NGINX, реализующего
протокол NoiseSocket.
Я хотел бы описать цели, результаты и узнать мнение о решениях и спросить
совета о других путях решения задачи.
Протокол NoiseSocket позиционируется как более простая в реализации и
быстрая альтернатива TLS. Одной из его главных фич является возможность
установки безопасного соединения без использования сертификатов, используя
лишь "сырые" приватные\публичные ключи. Это необходимо для IoT, бекендов,
p2p и многих других задач.
Основной целью создания модуля для NGINX - это обеспечение функциональности
reverse proxy и load balancing, где соединение между прокси-сервером и
backend серверами осуществляется по протоколу NoiseSocket. Второй целью
является возможность принимать входящие соединения по протоколу NoiseSocket,
то есть обеспечивать поддержку протокола на стороне backend с помощью NGINX.
Для обеспечения нужного функционала модуль должен обеспечить:
1 При создании соединения на стороне noise client инициировать и отработать
handshake phase по алгоритму noise initiator.
2 При входящем соединении на стороне noise server ответить на входящие
handshake сообщения и отработать handshake phase по алгоритму noise .
3 После успешного завершения handshake phase упаковывать/распаковывать
сетевой траффик в NoiseSocket transport messages.
Сначала была рассмотрена возможность создания модуля для контекста http,
однако здесь траффик для сторонних модулей предоставляется в виде
составляющих http, что не дает возможности для работы протокола, имеющего
более низкий уровень, чем http.
Затем был рассмотрен вариант для контекста stream. Однако предоставляемый
функционал для сторонних модулей здесь оказался весьма ограничен. Здесь для
работы протокола уровня представления есть возможность только на стороне
noise server, когда появляется входящее соединение и можно прицепить модуль
к одной из фаз обработки входящего запроса. На стороне noise client такой
возможности нет, потому что здесь имеется функционал только для custom load
balancing. Мы можем добавить свой обработчик:
ngx_stream_session_t->peer.get(ngx_peer_connection_t *pc,void *data);
Однако его вызов осуществляется до создания соединения:
В файле ngx_event_connect.c:
ngx_int_t ngx_event_connect_peer(ngx_peer_connection_t *pc)
{
:.
rc = pc->get(pc, pc->data);
:.
c = ngx_get_connection(s, pc->log);
:
}
Таким образом нет никакой возможности инициировать процедуру handshake и
назначить свои обработчики recv, send, recv_chain, send_chain для обработки
траффика средствами стороннего модуля.
В итоге было принято решение создать модуль, реализующий собственный
контекст по обработке траффика. За основу был взят код контекста stream, где
был убран TLS, и добавлен NoiseSocket.
Для обработки траффика только по протоколу NoiseSocket приемлема следующая
конфигурация, которая наиболее оптимальна по быстродействию:

https://i.imgur.com/fucb9J0.png

В итоге для сохранения существующего функционала NGINX по обработке http
контента определена следующая конфигурация:

https://i.imgur.com/6vnOdwd.png

или
https://i.imgur.com/WpMhdKh.png

Так как подобная конфигурация не оптимальна в плане быстродействия, то
хотелось бы узнать о более перспективных вариантах внедрения протокола
уровня представления для NGINX в качестве модуля.
Рабочий вариант спецификации для NoiseSocket:
http://noisesocket.com/spec/noisesocket/
Репозиторий с кодом модуля
https://github.com/VirgilSecurity/virgil-NGINX-noise-socket
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Docker & NGINX - (multiple) - Verständnisfrage

$
0
0
Hi, seit einiger Zeit betreibe ich einen eMail-Server mit der Docker-Repo mailcow. Diese beinhaltet neben den wichtigen eMail-Server-Elementen auch NGINX.
Nun möchte ich allerdings mehrere Websiten mit NGINX betreiben ohne die Docker - Installation von mailcow anzufassen. Ist es denn problemlos möglich einen neuen Docker-Container mit NGINX einzurichten um dann beide problemlos zu nutzen? Oder gibt es dann iwelche Komplikationen? ;)
Viewing all 53287 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>