[PATCH] Grammar fixes
# HG changeset patch # User Ville Skyttä # Date 1577258677 -7200 # Wed Dec 25 09:24:37 2019 +0200 # Node ID f4b83914e4009fb9c528f0318287a76aa0c7326f # Parent e99e9b0a8c51d59c7ee665489949d8556565adff Grammar fixes. diff --git a/docs/xml/nginx/changes.xml b/docs/xml/nginx/changes.xml --- a/docs/xml/nginx/changes.xml +++ b/docs/xml/nginx/changes.xml @@ -14571,7 +14571,7 @@ a segmentation fault might occur in worker process, -if an "debug_connection" directive was used; +if a "debug_connection" directive was used; the bug had appeared in 0.7.54. @@ -15333,7 +15333,7 @@ теперь возвращается ошибка 403 вместо 500. -now if a file specified in a "auth_basic_user_file" directive is absent, +now if a file specified in an "auth_basic_user_file" directive is absent, then the 403 error is returned instead of the 500 one. @@ -15990,7 +15990,7 @@ теперь директива add_header не добавляет пустое значение. -now a "add_header" directive does not add an empty value. +now an "add_header" directive does not add an empty value. @@ -17769,7 +17769,7 @@ a segmentation fault occurred in worker process, -if big value was used in a "expires" directive. +if big value was used in an "expires" directive. Thanks to Joaquin Cuenca Abela. @@ -18443,7 +18443,7 @@ ошибка появилась в 0.6.11. -if the "?" character was in a "error_page" directive, then it was escaped +if the "?" character was in an "error_page" directive, then it was escape in a proxied request; the bug had appeared in 0.6.11. @@ -20715,7 +20715,7 @@ директива post_action могла не работать после неудачного завершения запроса. -the "post_action" directive might not run after a unsuccessful completion +the "post_action" directive might not run after an unsuccessful completion of a request. diff --git a/src/core/ngx_string.c b/src/core/ngx_string.c --- a/src/core/ngx_string.c +++ b/src/core/ngx_string.c @@ -519,7 +519,7 @@ * The glibc counterpart is about 150 lines of the code. * * For 32-bit numbers and some divisors gcc and icc use - * a inlined multiplication and shifts. For example, + * inlined multiplication and shifts. For example, * unsigned "i32 / 10" is compiled to * * (i32 * 0xCCCD) >> 35 diff --git a/src/event/modules/ngx_devpoll_module.c b/src/event/modules/ngx_devpoll_module.c --- a/src/event/modules/ngx_devpoll_module.c +++ b/src/event/modules/ngx_devpoll_module.c @@ -88,8 +88,8 @@ ngx_devpoll_del_event, /* delete an event */ ngx_devpoll_add_event, /* enable an event */ ngx_devpoll_del_event, /* disable an event */ -NULL, /* add an connection */ -NULL, /* delete an connection */ +NULL, /* add a connection */ +NULL, /* delete a connection */ NULL, /* trigger a notify */ ngx_devpoll_process_events,/* process the events */ ngx_devpoll_init, /* init the events */ diff --git a/src/event/modules/ngx_epoll_module.c b/src/event/modules/ngx_epoll_module.c --- a/src/event/modules/ngx_epoll_module.c +++ b/src/event/modules/ngx_epoll_module.c @@ -186,8 +186,8 @@ ngx_epoll_del_event, /* delete an event */ ngx_epoll_add_event, /* enable an event */ ngx_epoll_del_event, /* disable an event */ -ngx_epoll_add_connection,/* add an connection */ -ngx_epoll_del_connection,/* delete an connection */ +ngx_epoll_add_connection,/* add a connection */ +ngx_epoll_del_connection,/* delete a connection */ #if (NGX_HAVE_EVENTFD) ngx_epoll_notify,/* trigger a notify */ #else diff --git a/src/event/modules/ngx_eventport_module.c b/src/event/modules/ngx_eventport_module.c --- a/src/event/modules/ngx_eventport_module.c +++ b/src/event/modules/ngx_eventport_module.c @@ -181,8 +181,8 @@ ngx_eventport_del_event, /* delete an event */ ngx_eventport_add_event, /* enable an event */ ngx_eventport_del_event, /* disable an event */ -NULL, /* add an connection */ -NULL, /* delete an connection */ +NULL, /* add a connection */ +NULL, /* delete a connection */ ngx_eventport_notify, /* trigger a notify */ ngx_eventport_process_events, /* process the events */ ngx_eventport_init,/* init the events */ diff --git a/src/event/modules/ngx_iocp_module.c b/src/event/modules/ngx_iocp_module.c --- a/src/event/modules/ngx_iocp_module.c
Re: nginx - get value of the header - x_forwarded_for in Nginx module (Naxsi)
Thanks.
Works. For the reference, this is the code I used:
ngx_uint_t n;
ngx_table_elt_t **h;
ngx_array_t a;
a = req->headers_in.x_forwarded_for;
n = a.nelts;
h = a.elts;
for (i = 0; iconnection->log,
0, "x_forwarded_for: %s", h[i]->value.data);
}
BTW What would be the best practice in NGINX NASIX module or any other
module to load a file with hundreds entries of IPs (hashmap, or what
structure would be best?) which should be whitelisted later for comparison
in NASIX module logic. Those IP should never be blocked by NAXSI.
When should I load this file in memory, in which component
/module/function/step?
Links to some guides/sample code would be also appreciated.
Thanks,
On Tue, Dec 24, 2019 at 10:37 AM Ruslan Ermilov wrote:
> On Mon, Dec 23, 2019 at 11:04:43PM +0100, Marcin Kozlowski wrote:
> > Hi List,
> >
> > How to get x_forwarded_for sent in the request in NGINX module (NAXSI in
> > particular):
> >
> > My attempt:
> >
> > ngx_log_error(NGX_LOG_ERR, req->connection->log,
> > 0, "test %s", (char
> *)req->headers_in.x_forwarded_for.elts);
> >
> > The bigger problem I am trying to solve with NAXSI is this:
> >
> >
> https://stackoverflow.com/questions/59453729/naxsi-blacklist-and-whitelist-setup-with-nginx
> >
> > I want to simply create a map and check if X-forwarded-for is on the
> > whitelist and if yes, always allow it.
> >
> > Above does not work. Prints garabge. Why it is (void *) ???
> >
> > Debugging it:
> >
> > $1 = (ngx_http_request_t *) 0xa44df0
> > (gdb) p req->headers_
> > headers_in headers_out
> > (gdb) p req->headers_in
> > $2 = {headers = {last = 0xa44e60, part = {elts = 0xad4d10, nelts = 7,
> next
> > = 0x0}, size = 48, nalloc = 20,
> > pool = 0xa44da0}, host = 0xad4d10, connection = 0x0,
> if_modified_since
> > = 0x0, if_unmodified_since = 0x0,
> > if_match = 0x0, if_none_match = 0x0, user_agent = 0xad4d70, referer =
> > 0x0, content_length = 0x0,
> > content_range = 0x0, content_type = 0x0, range = 0x0, if_range = 0x0,
> > transfer_encoding = 0x0, te = 0x0,
> > expect = 0x0, upgrade = 0x0, accept_encoding = 0x0, via = 0x0,
> > authorization = 0x0, keep_alive = 0x0,
> > x_forwarded_for = {elts = 0xa45b98, nelts = 1, size = 8, nalloc = 1,
> pool
> > = 0xa44da0}, x_real_ip = 0x0, user = {
> > len = 0, data = 0x0}, passwd = {len = 0, data = 0x0}, cookies =
> {elts =
> > 0x0, nelts = 0, size = 0, nalloc = 0,
> > pool = 0x0}, server = {len = 32, data = 0xa449a9 "domain.com"},
> > content_length_n = -1,
> > keep_alive_n = -1, connection_type = 2, chunked = 0, msie = 0, msie6 =
> 0,
> > opera = 0, gecko = 0, chrome = 0,
> > safari = 0, konqueror = 0}
> > (gdb) p req->headers_in.x_forwarded_for
> > $3 = {elts = 0xa45b98, nelts = 1, size = 8, nalloc = 1, pool = 0xa44da0}
> > (gdb) p req->headers_in.x_forwarded_for .elts
> > $4 = (void *) 0xa45b98
> > (gdb) p req->headers_in.x_forwarded_for.elts
> > $5 = (void *) 0xa45b98
> >
> > What structure is this? Linked List? Why the elts point to garbage, when
> I
> > know the Loadbalancer added the X-Forwarded-for header with value.
>
> It's an array of type ngx_table_elt_t, the number of elements is
> in "nelts". Please see the handler for the $http_x_forwarded_for
> variable in the ngx_http_variables.c on how to work with it.
> ___
> 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
Re: Fwd: 1.17.5 regression
Hello! On Tue, Dec 24, 2019 at 08:59:46AM -0800, Maksim Yevmenkin wrote: > > Just to make sure it's known: the patch above was committed after > > internal review/testing, and it is available as part of the 1.17.7 > > release. > > would it be possible to publish 1.17.7 to https://github.com/nginx/nginx.git > ? Official repository is at hg.nginx.org/nginx, consider using it instead. Github mirror likely will be fixed as well at some point, though no ETA. -- Maxim Dounin http://mdounin.ru/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Fwd: 1.17.5 regression
hello! > Just to make sure it's known: the patch above was committed after > internal review/testing, and it is available as part of the 1.17.7 > release. would it be possible to publish 1.17.7 to https://github.com/nginx/nginx.git ? thanks! max ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Fwd: 1.17.5 regression
Maxim Dounin ezt írta (időpont: 2019. dec. 24., K, 17:46): > > Hello! > > On Tue, Dec 24, 2019 at 04:45:20PM +0100, Gábor Boskovits wrote: > > > Maxim Dounin ezt írta (időpont: 2019. dec. 23., H, > > 20:28): > > > > > > Hello! > > > > > > On Wed, Dec 18, 2019 at 08:24:25PM +0300, Maxim Dounin wrote: > > > > > > > On Mon, Dec 16, 2019 at 03:02:37PM +0100, Gábor Boskovits wrote: > > > > > > > > > On berlin.guix.gnu.org we observed a regression upon upgrading nginx > > > > > to 1.17.5. The problem was, when pipelining request to a proxy using > > > > > tls, we suddenly started to get 408 client timeouts, manifesting in > > > > > dropped connections. Currently we worked around the issue by > > > > > downgrading to 1.17.4. I have collected some information about the > > > > > problem here: > > > > > https://gitlab.com/g_bor/fix-nginx-tls > > > > > It contains the logs from the good and the bad version, a full nginx > > > > > config, some info about how nginx was built. I managed to bisect the > > > > > problem down to changeset 9d2ad2fb4423, which introduced the problem. > > > > > Any help in further debuggin this would be greatly appreciated. > > > > > > > > Thanks for the report, it indeed looks like a bug introduced > > > > in 9d2ad2fb4423. > > > > > > > > The problem is that c->read->handler is overwritted when switching > > > > to the next pipelined request, ngx_ssl_next_read_handler() is not > > > > called, and c->read->ready remains not set. I'll take a look how > > > > to fix it properly. > > > > > > Please try the following patch: > > > > > > # HG changeset patch > > > # User Maxim Dounin > > > # Date 1577129029 -10800 > > > # Mon Dec 23 22:23:49 2019 +0300 > > > # Node ID c2dc6bfd2a0bce28618ef96b87fbdb63c6010575 > > > # Parent 8e64e11aaca02d50649cd2d9b448508f5b268062 > > > SSL: reworked posted next events. > > > > > > Introduced in 9d2ad2fb4423 available bytes handling in SSL relied > > > on connection read handler being overwritten to set the ready flag > > > and the amount of available bytes. This approach is, however, does > > > not work properly when connection read handler is changed, for example, > > > when switching to a next pipelined request, and can result in unexpected > > > connection timeouts, see here: > > > > > > http://mailman.nginx.org/pipermail/nginx-devel/2019-December/012825.html > > > > > > Fix is to introduce ngx_event_process_posted_next() instead, which > > > will set ready and available regardless of how event handler is set. > > [...] > > > Thanks for having a look at this. I will coordinate with others as > > when can we schedule a service restart. > > I will report back with the results soon. > > > > I wish you a merry christmas, and thanks for the great work all around the > > year! > > Just to make sure it's known: the patch above was committed after > internal review/testing, and it is available as part of the 1.17.7 > release. Thanks very much for the info. > > Merry Christmas! > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-devel mailing list > nginx-devel@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Fwd: 1.17.5 regression
Hello! On Tue, Dec 24, 2019 at 04:45:20PM +0100, Gábor Boskovits wrote: > Maxim Dounin ezt írta (időpont: 2019. dec. 23., H, > 20:28): > > > > Hello! > > > > On Wed, Dec 18, 2019 at 08:24:25PM +0300, Maxim Dounin wrote: > > > > > On Mon, Dec 16, 2019 at 03:02:37PM +0100, Gábor Boskovits wrote: > > > > > > > On berlin.guix.gnu.org we observed a regression upon upgrading nginx > > > > to 1.17.5. The problem was, when pipelining request to a proxy using > > > > tls, we suddenly started to get 408 client timeouts, manifesting in > > > > dropped connections. Currently we worked around the issue by > > > > downgrading to 1.17.4. I have collected some information about the > > > > problem here: > > > > https://gitlab.com/g_bor/fix-nginx-tls > > > > It contains the logs from the good and the bad version, a full nginx > > > > config, some info about how nginx was built. I managed to bisect the > > > > problem down to changeset 9d2ad2fb4423, which introduced the problem. > > > > Any help in further debuggin this would be greatly appreciated. > > > > > > Thanks for the report, it indeed looks like a bug introduced > > > in 9d2ad2fb4423. > > > > > > The problem is that c->read->handler is overwritted when switching > > > to the next pipelined request, ngx_ssl_next_read_handler() is not > > > called, and c->read->ready remains not set. I'll take a look how > > > to fix it properly. > > > > Please try the following patch: > > > > # HG changeset patch > > # User Maxim Dounin > > # Date 1577129029 -10800 > > # Mon Dec 23 22:23:49 2019 +0300 > > # Node ID c2dc6bfd2a0bce28618ef96b87fbdb63c6010575 > > # Parent 8e64e11aaca02d50649cd2d9b448508f5b268062 > > SSL: reworked posted next events. > > > > Introduced in 9d2ad2fb4423 available bytes handling in SSL relied > > on connection read handler being overwritten to set the ready flag > > and the amount of available bytes. This approach is, however, does > > not work properly when connection read handler is changed, for example, > > when switching to a next pipelined request, and can result in unexpected > > connection timeouts, see here: > > > > http://mailman.nginx.org/pipermail/nginx-devel/2019-December/012825.html > > > > Fix is to introduce ngx_event_process_posted_next() instead, which > > will set ready and available regardless of how event handler is set. [...] > Thanks for having a look at this. I will coordinate with others as > when can we schedule a service restart. > I will report back with the results soon. > > I wish you a merry christmas, and thanks for the great work all around the > year! Just to make sure it's known: the patch above was committed after internal review/testing, and it is available as part of the 1.17.7 release. Merry Christmas! -- Maxim Dounin http://mdounin.ru/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Fwd: 1.17.5 regression
Hello Maxim,
Maxim Dounin ezt írta (időpont: 2019. dec. 23., H, 20:28):
>
> Hello!
>
> On Wed, Dec 18, 2019 at 08:24:25PM +0300, Maxim Dounin wrote:
>
> > On Mon, Dec 16, 2019 at 03:02:37PM +0100, Gábor Boskovits wrote:
> >
> > > On berlin.guix.gnu.org we observed a regression upon upgrading nginx
> > > to 1.17.5. The problem was, when pipelining request to a proxy using
> > > tls, we suddenly started to get 408 client timeouts, manifesting in
> > > dropped connections. Currently we worked around the issue by
> > > downgrading to 1.17.4. I have collected some information about the
> > > problem here:
> > > https://gitlab.com/g_bor/fix-nginx-tls
> > > It contains the logs from the good and the bad version, a full nginx
> > > config, some info about how nginx was built. I managed to bisect the
> > > problem down to changeset 9d2ad2fb4423, which introduced the problem.
> > > Any help in further debuggin this would be greatly appreciated.
> >
> > Thanks for the report, it indeed looks like a bug introduced
> > in 9d2ad2fb4423.
> >
> > The problem is that c->read->handler is overwritted when switching
> > to the next pipelined request, ngx_ssl_next_read_handler() is not
> > called, and c->read->ready remains not set. I'll take a look how
> > to fix it properly.
>
> Please try the following patch:
>
> # HG changeset patch
> # User Maxim Dounin
> # Date 1577129029 -10800
> # Mon Dec 23 22:23:49 2019 +0300
> # Node ID c2dc6bfd2a0bce28618ef96b87fbdb63c6010575
> # Parent 8e64e11aaca02d50649cd2d9b448508f5b268062
> SSL: reworked posted next events.
>
> Introduced in 9d2ad2fb4423 available bytes handling in SSL relied
> on connection read handler being overwritten to set the ready flag
> and the amount of available bytes. This approach is, however, does
> not work properly when connection read handler is changed, for example,
> when switching to a next pipelined request, and can result in unexpected
> connection timeouts, see here:
>
> http://mailman.nginx.org/pipermail/nginx-devel/2019-December/012825.html
>
> Fix is to introduce ngx_event_process_posted_next() instead, which
> will set ready and available regardless of how event handler is set.
>
> diff --git a/src/event/ngx_event.c b/src/event/ngx_event.c
> --- a/src/event/ngx_event.c
> +++ b/src/event/ngx_event.c
> @@ -238,8 +238,6 @@ ngx_process_events_and_timers(ngx_cycle_
> }
>
> if (!ngx_queue_empty(_posted_next_events)) {
> -ngx_queue_add(_posted_events, _posted_next_events);
> -ngx_queue_init(_posted_next_events);
> timer = 0;
> }
>
> @@ -263,6 +261,7 @@ ngx_process_events_and_timers(ngx_cycle_
> }
>
> ngx_event_process_posted(cycle, _posted_events);
> +ngx_event_process_posted_next(cycle, _posted_next_events);
> }
>
>
> diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
> --- a/src/event/ngx_event_openssl.c
> +++ b/src/event/ngx_event_openssl.c
> @@ -43,7 +43,6 @@ static ssize_t ngx_ssl_recv_early(ngx_co
> #endif
> static ngx_int_t ngx_ssl_handle_recv(ngx_connection_t *c, int n);
> static void ngx_ssl_write_handler(ngx_event_t *wev);
> -static void ngx_ssl_next_read_handler(ngx_event_t *rev);
> #ifdef SSL_READ_EARLY_DATA_SUCCESS
> static ssize_t ngx_ssl_write_early(ngx_connection_t *c, u_char *data,
> size_t size);
> @@ -2018,11 +2017,6 @@ ngx_ssl_recv(ngx_connection_t *c, u_char
> c->read->available = 0;
> c->read->ready = 0;
>
> -if (c->ssl->next_read_handler == NULL) {
> -c->ssl->next_read_handler = c->read->handler;
> -c->read->handler = ngx_ssl_next_read_handler;
> -}
> -
> ngx_post_event(c->read, _posted_next_events);
> }
>
> @@ -2328,31 +2322,6 @@ ngx_ssl_write_handler(ngx_event_t *wev)
> }
>
>
> -static void
> -ngx_ssl_next_read_handler(ngx_event_t *rev)
> -{
> -ngx_connection_t *c;
> -
> -c = rev->data;
> -
> -ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0, "SSL next read handler");
> -
> -rev->handler = c->ssl->next_read_handler;
> -c->ssl->next_read_handler = NULL;
> -
> -if (!rev->ready) {
> -rev->ready = 1;
> -rev->available = -1;
> -}
> -
> -if (rev->posted) {
> -ngx_delete_posted_event(rev);
> -}
> -
> -rev->handler(rev);
> -}
> -
> -
> /*
> * OpenSSL has no SSL_writev() so we copy several bufs into our 16K buffer
> * before the SSL_write() call to decrease a SSL overhead.
> diff --git a/src/event/ngx_event_openssl.h b/src/event/ngx_event_openssl.h
> --- a/src/event/ngx_event_openssl.h
> +++ b/src/event/ngx_event_openssl.h
> @@ -86,7 +86,6 @@ struct ngx_ssl_connection_s {
>
> ngx_event_handler_ptsaved_read_handler;
> ngx_event_handler_ptsaved_write_handler;
> -ngx_event_handler_ptnext_read_handler;
>
> u_char
[nginx] nginx-1.17.7-RELEASE
details: https://hg.nginx.org/nginx/rev/e56295fe0ea7 branches: changeset: 7613:e56295fe0ea7 user: Maxim Dounin date: Tue Dec 24 18:00:09 2019 +0300 description: nginx-1.17.7-RELEASE diffstat: docs/xml/nginx/changes.xml | 84 ++ 1 files changed, 84 insertions(+), 0 deletions(-) diffs (94 lines): diff --git a/docs/xml/nginx/changes.xml b/docs/xml/nginx/changes.xml --- a/docs/xml/nginx/changes.xml +++ b/docs/xml/nginx/changes.xml @@ -5,6 +5,90 @@ + + + + +на старте или во время переконфигурации мог произойти segmentation fault, +если в конфигурации использовалась +директива rewrite с пустой строкой замены. + + +a segmentation fault might occur on start or during reconfiguration +if the "rewrite" directive with an empty replacement string +was used in the configuration. + + + + + +в рабочем процессе мог произойти segmentation fault, +если директива break использовалась совместно с директивой alias +или директивой proxy_pass с URI. + + +a segmentation fault might occur in a worker process +if the "break" directive was used with the "alias" directive +or with the "proxy_pass" directive with a URI. + + + + + +строка Location заголовка ответа могла содержать мусор, +если URI запроса был изменён на URI, содержащий нулевой символ. + + +the "Location" response header line might contain garbage +if the request URI was rewritten to the one containing a null character. + + + + + +при возврате перенаправлений с помощью директивы error_page +запросы с телом обрабатывались некорректно; +ошибка появилась в 0.7.12. + + +requests with bodies were handled incorrectly +when returning redirections with the "error_page" directive; +the bug had appeared in 0.7.12. + + + + + +утечки сокетов при использовании HTTP/2. + + +socket leak when using HTTP/2. + + + + + +при обработке pipelined-запросов по SSL-соединению мог произойти таймаут; +ошибка появилась в 1.17.5. + + +a timeout might occur while handling pipelined requests in an SSL connection; +the bug had appeared in 1.17.5. + + + + + +в модуле ngx_http_dav_module. + + +in the ngx_http_dav_module. + + + + + + ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] release-1.17.7 tag
details: https://hg.nginx.org/nginx/rev/e99e9b0a8c51 branches: changeset: 7614:e99e9b0a8c51 user: Maxim Dounin date: Tue Dec 24 18:00:09 2019 +0300 description: release-1.17.7 tag diffstat: .hgtags | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (8 lines): diff --git a/.hgtags b/.hgtags --- a/.hgtags +++ b/.hgtags @@ -445,3 +445,4 @@ ed4303aa1b31a9aad5440640c0840d9d0af45fed ce2ced3856909f36f8130c99eaa4dbdbae636ddc release-1.17.4 9af0dddbddb2c368bfedd2801bc100ffad01e19b release-1.17.5 de68d0d94320cbf033599c6f3ca37e5335c67fd7 release-1.17.6 +e56295fe0ea76bf53b06bffa77a2d3a9a335cb8c release-1.17.7 ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] SSL: reworked posted next events.
details: https://hg.nginx.org/nginx/rev/1ce3f01a4355
branches:
changeset: 7612:1ce3f01a4355
user: Maxim Dounin
date: Tue Dec 24 17:24:59 2019 +0300
description:
SSL: reworked posted next events.
Introduced in 9d2ad2fb4423 available bytes handling in SSL relied
on connection read handler being overwritten to set the ready flag
and the amount of available bytes. This approach is, however, does
not work properly when connection read handler is changed, for example,
when switching to a next pipelined request, and can result in unexpected
connection timeouts, see here:
http://mailman.nginx.org/pipermail/nginx-devel/2019-December/012825.html
Fix is to introduce ngx_event_process_posted_next() instead, which
will set ready and available regardless of how event handler is set.
diffstat:
src/event/ngx_event.c | 3 +--
src/event/ngx_event_openssl.c | 31 ---
src/event/ngx_event_openssl.h | 1 -
src/event/ngx_event_posted.c | 26 ++
src/event/ngx_event_posted.h | 1 +
5 files changed, 28 insertions(+), 34 deletions(-)
diffs (130 lines):
diff --git a/src/event/ngx_event.c b/src/event/ngx_event.c
--- a/src/event/ngx_event.c
+++ b/src/event/ngx_event.c
@@ -238,8 +238,6 @@ ngx_process_events_and_timers(ngx_cycle_
}
if (!ngx_queue_empty(_posted_next_events)) {
-ngx_queue_add(_posted_events, _posted_next_events);
-ngx_queue_init(_posted_next_events);
timer = 0;
}
@@ -263,6 +261,7 @@ ngx_process_events_and_timers(ngx_cycle_
}
ngx_event_process_posted(cycle, _posted_events);
+ngx_event_process_posted_next(cycle, _posted_next_events);
}
diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -43,7 +43,6 @@ static ssize_t ngx_ssl_recv_early(ngx_co
#endif
static ngx_int_t ngx_ssl_handle_recv(ngx_connection_t *c, int n);
static void ngx_ssl_write_handler(ngx_event_t *wev);
-static void ngx_ssl_next_read_handler(ngx_event_t *rev);
#ifdef SSL_READ_EARLY_DATA_SUCCESS
static ssize_t ngx_ssl_write_early(ngx_connection_t *c, u_char *data,
size_t size);
@@ -2018,11 +2017,6 @@ ngx_ssl_recv(ngx_connection_t *c, u_char
c->read->available = 0;
c->read->ready = 0;
-if (c->ssl->next_read_handler == NULL) {
-c->ssl->next_read_handler = c->read->handler;
-c->read->handler = ngx_ssl_next_read_handler;
-}
-
ngx_post_event(c->read, _posted_next_events);
}
@@ -2328,31 +2322,6 @@ ngx_ssl_write_handler(ngx_event_t *wev)
}
-static void
-ngx_ssl_next_read_handler(ngx_event_t *rev)
-{
-ngx_connection_t *c;
-
-c = rev->data;
-
-ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0, "SSL next read handler");
-
-rev->handler = c->ssl->next_read_handler;
-c->ssl->next_read_handler = NULL;
-
-if (!rev->ready) {
-rev->ready = 1;
-rev->available = -1;
-}
-
-if (rev->posted) {
-ngx_delete_posted_event(rev);
-}
-
-rev->handler(rev);
-}
-
-
/*
* OpenSSL has no SSL_writev() so we copy several bufs into our 16K buffer
* before the SSL_write() call to decrease a SSL overhead.
diff --git a/src/event/ngx_event_openssl.h b/src/event/ngx_event_openssl.h
--- a/src/event/ngx_event_openssl.h
+++ b/src/event/ngx_event_openssl.h
@@ -86,7 +86,6 @@ struct ngx_ssl_connection_s {
ngx_event_handler_ptsaved_read_handler;
ngx_event_handler_ptsaved_write_handler;
-ngx_event_handler_ptnext_read_handler;
u_char early_buf;
diff --git a/src/event/ngx_event_posted.c b/src/event/ngx_event_posted.c
--- a/src/event/ngx_event_posted.c
+++ b/src/event/ngx_event_posted.c
@@ -34,3 +34,29 @@ ngx_event_process_posted(ngx_cycle_t *cy
ev->handler(ev);
}
}
+
+
+void
+ngx_event_process_posted_next(ngx_cycle_t *cycle, ngx_queue_t *posted)
+{
+ngx_queue_t *q;
+ngx_event_t *ev;
+
+while (!ngx_queue_empty(posted)) {
+
+q = ngx_queue_head(posted);
+ev = ngx_queue_data(q, ngx_event_t, queue);
+
+ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
+ "posted next event %p", ev);
+
+ngx_delete_posted_event(ev);
+
+if (!ev->ready) {
+ev->ready = 1;
+ev->available = -1;
+}
+
+ev->handler(ev);
+}
+}
diff --git a/src/event/ngx_event_posted.h b/src/event/ngx_event_posted.h
--- a/src/event/ngx_event_posted.h
+++ b/src/event/ngx_event_posted.h
@@ -39,6 +39,7 @@
void ngx_event_process_posted(ngx_cycle_t *cycle, ngx_queue_t *posted);
+void ngx_event_process_posted_next(ngx_cycle_t *cycle, ngx_queue_t *posted);
extern ngx_queue_t ngx_posted_accept_events;
Re: nginx - get value of the header - x_forwarded_for in Nginx module (Naxsi)
On Mon, Dec 23, 2019 at 11:04:43PM +0100, Marcin Kozlowski wrote:
> Hi List,
>
> How to get x_forwarded_for sent in the request in NGINX module (NAXSI in
> particular):
>
> My attempt:
>
> ngx_log_error(NGX_LOG_ERR, req->connection->log,
> 0, "test %s", (char *)req->headers_in.x_forwarded_for.elts);
>
> The bigger problem I am trying to solve with NAXSI is this:
>
> https://stackoverflow.com/questions/59453729/naxsi-blacklist-and-whitelist-setup-with-nginx
>
> I want to simply create a map and check if X-forwarded-for is on the
> whitelist and if yes, always allow it.
>
> Above does not work. Prints garabge. Why it is (void *) ???
>
> Debugging it:
>
> $1 = (ngx_http_request_t *) 0xa44df0
> (gdb) p req->headers_
> headers_in headers_out
> (gdb) p req->headers_in
> $2 = {headers = {last = 0xa44e60, part = {elts = 0xad4d10, nelts = 7, next
> = 0x0}, size = 48, nalloc = 20,
> pool = 0xa44da0}, host = 0xad4d10, connection = 0x0, if_modified_since
> = 0x0, if_unmodified_since = 0x0,
> if_match = 0x0, if_none_match = 0x0, user_agent = 0xad4d70, referer =
> 0x0, content_length = 0x0,
> content_range = 0x0, content_type = 0x0, range = 0x0, if_range = 0x0,
> transfer_encoding = 0x0, te = 0x0,
> expect = 0x0, upgrade = 0x0, accept_encoding = 0x0, via = 0x0,
> authorization = 0x0, keep_alive = 0x0,
> x_forwarded_for = {elts = 0xa45b98, nelts = 1, size = 8, nalloc = 1, pool
> = 0xa44da0}, x_real_ip = 0x0, user = {
> len = 0, data = 0x0}, passwd = {len = 0, data = 0x0}, cookies = {elts =
> 0x0, nelts = 0, size = 0, nalloc = 0,
> pool = 0x0}, server = {len = 32, data = 0xa449a9 "domain.com"},
> content_length_n = -1,
> keep_alive_n = -1, connection_type = 2, chunked = 0, msie = 0, msie6 = 0,
> opera = 0, gecko = 0, chrome = 0,
> safari = 0, konqueror = 0}
> (gdb) p req->headers_in.x_forwarded_for
> $3 = {elts = 0xa45b98, nelts = 1, size = 8, nalloc = 1, pool = 0xa44da0}
> (gdb) p req->headers_in.x_forwarded_for .elts
> $4 = (void *) 0xa45b98
> (gdb) p req->headers_in.x_forwarded_for.elts
> $5 = (void *) 0xa45b98
>
> What structure is this? Linked List? Why the elts point to garbage, when I
> know the Loadbalancer added the X-Forwarded-for header with value.
It's an array of type ngx_table_elt_t, the number of elements is
in "nelts". Please see the handler for the $http_x_forwarded_for
variable in the ngx_http_variables.c on how to work with it.
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
