Відповідь: Как убрать слеш / из начала $request uri

[Dmytro Lavryk]

rewrite ^/(.+) https://google.com/search?q=$1 redirect;

 Увімкнуто чт, 25 бер. 2021 22:59:30 +0200 maximkherson 
 написав 


Приветсвую!
Делаю редирект с локального хочта на гугл.
В начальном запросе в браузере после / идёт поисковый запрос:
http://redirect.localhost/hello

Далее происходит редирект на google.com/search?q=
и проблема в том, что не знаю как добавить к этому адресу
(google.com/search?q=) $request_uri без слеша в начале.

Получается вот так:
https://www.google.com/search?q=/hello
а надо так:
https://www.google.com/search?q=hello

Мой код:
server {
<-->listen *:80;
<-->server_name redirect.localhost;
<-->return 302 https://google.com/search?q=$request_uri;
}

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,291051,291051#msg-291051

___
nginx-ru mailing list
mailto: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

[Alexey]

Както так ?
proxy_store /data/www/$uri/$request_id ?

25.03.2021 16:07, Vitaliy Okulov пишет:
Я так понимаю что возникнут проблемы с уникальностью данных в 
зависимости от пользователя, запроса который он создает и т.д.


чт, 25 мар. 2021 г. в 14:30, Илья Шипицин >:


proxy_store ?

чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov
mailto:vitaliy.oku...@gmail.com>>:

Добрый день.
Подскажите что можно сделать в ситуации когда требуется писать
в файл тело ответа сервиса, попробовал вариант с обработкой в
body_filter_by_lua, но при больших телах ответа воркер
блокируется и потребляет 100% CPU
Какие еще варианты реализовать задачу на уровне nginx возможны?
___
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



___
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

[nginx] HTTP/2: improved handling of "keepalive_timeout 0".

[Maxim Dounin]

details:   https://hg.nginx.org/nginx/rev/ade8160120c1
branches:  
changeset: 7805:ade8160120c1
user:  Maxim Dounin 
date:  Fri Mar 26 01:44:57 2021 +0300
description:
HTTP/2: improved handling of "keepalive_timeout 0".

Without explicit handling, a zero timer was actually added, leading to
multiple unneeded syscalls.  Further, sending GOAWAY frame early might
be beneficial for clients.

Reported by Sergey Kandaurov.

diffstat:

 src/http/v2/ngx_http_v2.c |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diffs (14 lines):

diff -r 4a9d28f8f39e -r ade8160120c1 src/http/v2/ngx_http_v2.c
--- a/src/http/v2/ngx_http_v2.c Wed Mar 24 14:03:33 2021 +0300
+++ b/src/http/v2/ngx_http_v2.c Fri Mar 26 01:44:57 2021 +0300
@@ -1368,7 +1368,9 @@ ngx_http_v2_state_headers(ngx_http_v2_co
 clcf = ngx_http_get_module_loc_conf(h2c->http_connection->conf_ctx,
 ngx_http_core_module);
 
-if (h2c->connection->requests >= clcf->keepalive_requests) {
+if (clcf->keepalive_timeout == 0
+|| h2c->connection->requests >= clcf->keepalive_requests)
+{
 h2c->goaway = 1;
 
 if (ngx_http_v2_send_goaway(h2c, NGX_HTTP_V2_NO_ERROR) == NGX_ERROR) {
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[nginx] Events: fixed expiration of timers in the past.

[Maxim Dounin]

details:   https://hg.nginx.org/nginx/rev/2ed5d03c2d90
branches:  
changeset: 7806:2ed5d03c2d90
user:  Maxim Dounin 
date:  Fri Mar 26 01:44:59 2021 +0300
description:
Events: fixed expiration of timers in the past.

If, at the start of an event loop iteration, there are any timers
in the past (including timers expiring now), the ngx_process_events()
function is called with zero timeout, and returns immediately even
if there are no events.  But the following code only calls
ngx_event_expire_timers() if time actually changed, so this results
in nginx spinning in the event loop till current time changes.

While such timers are not expected to appear under normal conditions,
as all such timers should be removed on previous event loop iterations,
they still can appear due to bugs, zero timeouts set in the configuration
(if this is not explicitly handled by the code), or due to external
time changes on systems without clock_gettime(CLOCK_MONOTONIC).

Fix is to call ngx_event_expire_timers() unconditionally.  Calling
it on each event loop iteration is not expected to be significant from
performance point of view, especially compared to a syscall in
ngx_process_events().

diffstat:

 src/event/ngx_event.c |  4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diffs (14 lines):

diff -r ade8160120c1 -r 2ed5d03c2d90 src/event/ngx_event.c
--- a/src/event/ngx_event.c Fri Mar 26 01:44:57 2021 +0300
+++ b/src/event/ngx_event.c Fri Mar 26 01:44:59 2021 +0300
@@ -257,9 +257,7 @@ ngx_process_events_and_timers(ngx_cycle_
 ngx_shmtx_unlock(_accept_mutex);
 }
 
-if (delta) {
-ngx_event_expire_timers();
-}
+ngx_event_expire_timers();
 
 ngx_event_process_posted(cycle, _posted_events);
 }
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Как убрать слеш / из начала $request uri

[maximkherson]

Приветсвую!
Делаю редирект с локального хочта на гугл.
В начальном запросе в браузере после / идёт поисковый запрос:
http://redirect.localhost/hello

Далее происходит редирект на google.com/search?q=
и проблема в том, что не знаю как добавить к этому адресу
(google.com/search?q=) $request_uri без слеша в начале.

Получается вот так:
https://www.google.com/search?q=/hello
а надо так:
https://www.google.com/search?q=hello

Мой код:
server {
<-->listen *:80;
<-->server_name redirect.localhost;
<-->return 302 https://google.com/search?q=$request_uri;
}

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,291051,291051#msg-291051

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

rate limit by header or API key

[Andy Meadows]

using nginx open source, is there an option to provide a custom rate limit
by user agent, http header value, or an API key?  Looking for the best
option to provide custom rate limits to named users, but the traffic is
coming from unpredictable IP addresses.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

[nginx-announce] unit-1.23.0

[Valentin V. Bartenev]

Hi,

I'm glad to announce a new release of NGINX Unit.

Nowadays, TLS is everywhere, while plain HTTP is almost nonexistent in the
global network.  We are fully aware of this trend and strive to simplify TLS
configuration in Unit as much as possible.  Frankly, there's still much to do,
but the introduction of smart SNI certificate selection marks yet another step
in this direction.

Perhaps, you already know about Unit's certificate storage API that uploads
certificate bundles to a running instance.  Otherwise, if you're not yet fully
informed but still curious, here's a decent overview:

 - https://unit.nginx.org/configuration/#certificate-management

Basically, you just upload a certificate chain and a key under some name; after
that, you can specify the name ("mycert" in the example below) with any
listening socket to configure it for HTTPS:

  {
  "listeners": {
  "*:443": {
  "tls": {
  "certificate": "mycert"
  },

  "pass": "routes"
  }
  }
  }

Unit's API also enables informative introspection of uploaded certificate
bundles so you can monitor their validity and benefit from service discovery.

You can also upload any number of certificate bundles to switch between them on
the fly without restarting the server (yes, Unit's dynamic nature is exactly
like that).  Still, with this release, there are even more options, as you can
supply any number of certificate bundle names with a listener socket:

  {
  "certificate": [ "mycertA", "mycertB", ... ]
  }

For each client, Unit automatically selects a suitable certificate from the
list depending on the domain name the client connects to (and therefore supplies
via the "Server Name Indication" TLS extension).  Thus, you don't even need to
care about matching certificates to server names; Unit handles that for you.
As a result, there's almost no room for a mistake, which spares more time for
stuff that matters.

As one can reasonably expect, you can always add more certs, delete them, or
edit the cert list on the fly without compromising performance.
That's the Unit way!

In case you're wondering whom to thank for this shiny new feature: give a
warm welcome to Andrey Suvorov, a new developer on our team.  He will continue
working on TLS improvements in Unit, and his TODO list is already stacked.
Still, if you'd like to suggest a concept or have a particular interest in
some feature, just start a ticket on GitHub; we are open to your ideas:

 - https://github.com/nginx/unit/issues

Also, plenty of solid bug fixing work was done by the whole team.  See the full
change log below:


Changes with Unit 1.23.0 25 Mar 2021

*) Feature: support for multiple certificate bundles on a listener via
   the Server Name Indication (SNI) TLS extension.

*) Feature: "--mandir" ./configure option to specify the directory for
   man page installation.

*) Bugfix: the router process could crash on premature TLS connection
   close; the bug had appeared in 1.17.0.

*) Bugfix: a connection leak occurred on premature TLS connection close;
   the bug had appeared in 1.6.

*) Bugfix: a descriptor and memory leak occurred in the router process
   when processing small WebSocket frames from a client; the bug had
   appeared in 1.19.0.

*) Bugfix: a descriptor leak occurred in the router process when
   removing or reconfiguring an application; the bug had appeared in
   1.19.0.

*) Bugfix: persistent storage of certificates might've not worked with
   some filesystems in Linux, and all uploaded certificate bundles were
   forgotten after restart.

*) Bugfix: the controller process could crash while requesting
   information about a certificate with a non-DNS SAN entry.

*) Bugfix: the controller process could crash on manipulations with a
   certificate containing a SAN and no standard name attributes in
   subject or issuer.

*) Bugfix: the Ruby module didn't respect the user locale for defaults
   in the Encoding class.

*) Bugfix: the PHP 5 module failed to build with thread safety enabled;
   the bug had appeared in 1.22.0.


Other notable features we are working on include:

 - statistics API
 - process control API
 - chrooting on a per-request basis during static file serving
 - MIME types filtering for static files
 - configuring ciphers and other OpenSSL settings

So much more to come!

Also, if you'd like to know more about Unit and prefer watching fun videos
instead of reading tedious documentation, I'm happy to recommend Timo Stark,
our own PM Engineer.  Recently, he started regularly streaming on Twitch and
YouTube:

 - https://www.twitch.tv/h30ne
 - https://www.youtube.com/Tippexs91

Tomorrow (March 26), at 10 p.m. CET (or 2 p.m. PDT), he is going on air to
livestream his using Unit's brand-new SNI feature to automate the certbot
setup:

 - 

Unit 1.23.0 release

[Valentin V. Bartenev]

Hi,

I'm glad to announce a new release of NGINX Unit.

Nowadays, TLS is everywhere, while plain HTTP is almost nonexistent in the
global network.  We are fully aware of this trend and strive to simplify TLS
configuration in Unit as much as possible.  Frankly, there's still much to do,
but the introduction of smart SNI certificate selection marks yet another step
in this direction.

Perhaps, you already know about Unit's certificate storage API that uploads
certificate bundles to a running instance.  Otherwise, if you're not yet fully
informed but still curious, here's a decent overview:

 - https://unit.nginx.org/configuration/#certificate-management

Basically, you just upload a certificate chain and a key under some name; after
that, you can specify the name ("mycert" in the example below) with any
listening socket to configure it for HTTPS:

  {
  "listeners": {
  "*:443": {
  "tls": {
  "certificate": "mycert"
  },

  "pass": "routes"
  }
  }
  }

Unit's API also enables informative introspection of uploaded certificate
bundles so you can monitor their validity and benefit from service discovery.

You can also upload any number of certificate bundles to switch between them on
the fly without restarting the server (yes, Unit's dynamic nature is exactly
like that).  Still, with this release, there are even more options, as you can
supply any number of certificate bundle names with a listener socket:

  {
  "certificate": [ "mycertA", "mycertB", ... ]
  }

For each client, Unit automatically selects a suitable certificate from the
list depending on the domain name the client connects to (and therefore supplies
via the "Server Name Indication" TLS extension).  Thus, you don't even need to
care about matching certificates to server names; Unit handles that for you.
As a result, there's almost no room for a mistake, which spares more time for
stuff that matters.

As one can reasonably expect, you can always add more certs, delete them, or
edit the cert list on the fly without compromising performance.
That's the Unit way!

In case you're wondering whom to thank for this shiny new feature: give a
warm welcome to Andrey Suvorov, a new developer on our team.  He will continue
working on TLS improvements in Unit, and his TODO list is already stacked.
Still, if you'd like to suggest a concept or have a particular interest in
some feature, just start a ticket on GitHub; we are open to your ideas:

 - https://github.com/nginx/unit/issues

Also, plenty of solid bug fixing work was done by the whole team.  See the full
change log below:


Changes with Unit 1.23.0 25 Mar 2021

*) Feature: support for multiple certificate bundles on a listener via
   the Server Name Indication (SNI) TLS extension.

*) Feature: "--mandir" ./configure option to specify the directory for
   man page installation.

*) Bugfix: the router process could crash on premature TLS connection
   close; the bug had appeared in 1.17.0.

*) Bugfix: a connection leak occurred on premature TLS connection close;
   the bug had appeared in 1.6.

*) Bugfix: a descriptor and memory leak occurred in the router process
   when processing small WebSocket frames from a client; the bug had
   appeared in 1.19.0.

*) Bugfix: a descriptor leak occurred in the router process when
   removing or reconfiguring an application; the bug had appeared in
   1.19.0.

*) Bugfix: persistent storage of certificates might've not worked with
   some filesystems in Linux, and all uploaded certificate bundles were
   forgotten after restart.

*) Bugfix: the controller process could crash while requesting
   information about a certificate with a non-DNS SAN entry.

*) Bugfix: the controller process could crash on manipulations with a
   certificate containing a SAN and no standard name attributes in
   subject or issuer.

*) Bugfix: the Ruby module didn't respect the user locale for defaults
   in the Encoding class.

*) Bugfix: the PHP 5 module failed to build with thread safety enabled;
   the bug had appeared in 1.22.0.


Other notable features we are working on include:

 - statistics API
 - process control API
 - chrooting on a per-request basis during static file serving
 - MIME types filtering for static files
 - configuring ciphers and other OpenSSL settings

So much more to come!

Also, if you'd like to know more about Unit and prefer watching fun videos
instead of reading tedious documentation, I'm happy to recommend Timo Stark,
our own PM Engineer.  Recently, he started regularly streaming on Twitch and
YouTube:

 - https://www.twitch.tv/h30ne
 - https://www.youtube.com/Tippexs91

Tomorrow (March 26), at 10 p.m. CET (or 2 p.m. PDT), he is going on air to
livestream his using Unit's brand-new SNI feature to automate the certbot
setup:

 - 

Re: запись ответа от сервиса в лог файл nginx

[Vitaliy Okulov]

Я так понимаю что возникнут проблемы с уникальностью данных в зависимости
от пользователя, запроса который он создает и т.д.

чт, 25 мар. 2021 г. в 14:30, Илья Шипицин :

> proxy_store ?
>
> чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov :
>
>> Добрый день.
>> Подскажите что можно сделать в ситуации когда требуется писать в файл
>> тело ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua,
>> но при больших телах ответа воркер блокируется и потребляет 100% CPU
>> Какие еще варианты реализовать задачу на уровне nginx возможны?
>> ___
>> 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: запись ответа от сервиса в лог файл nginx

[Илья Шипицин]

proxy_store ?

чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov :

> Добрый день.
> Подскажите что можно сделать в ситуации когда требуется писать в файл тело
> ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, но
> при больших телах ответа воркер блокируется и потребляет 100% CPU
> Какие еще варианты реализовать задачу на уровне nginx возможны?
> ___
> 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

запись ответа от сервиса в лог файл nginx

[Vitaliy Okulov]

Добрый день.
Подскажите что можно сделать в ситуации когда требуется писать в файл тело
ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, но
при больших телах ответа воркер блокируется и потребляет 100% CPU
Какие еще варианты реализовать задачу на уровне nginx возможны?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru