most cases there should be additional details in the error log
explaining the reasons. If there aren't any, or reasons aren't
clear, it might be a good idea to dig further.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://m
luding internally
generated 502/504 in ngx_http_upstream_finalize_request(), and
intercepted errors in ngx_http_upstream_intercept_errors().
Quick look suggests there will be also issues with caching errors
after proxy_cache_bypass (errors won't be cached even if they
should), as well as
eaders_in.content_length_n = 0;
> return NGX_OK;
> }
> #endif
The patch is wrong, see here:
https://trac.nginx.org/nginx/ticket/1152#comment:6
The issue is in my TODO list. Once properly fixed, you'll be able
to merge the fix from freenginx.
Alternatively, consider submi
Hello!
On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:
> Maxim Dounin писал 2024-02-16 02:24:
> > Hello!
> >
> > Андрей, я тебе, как и многим другим, всемерно благодарен за
> > поддержку в 2019 и после (эта история, кстати, всё ещё
> > продолжает
ругих рисков
тут не просматривается при всём желании.
> Единственное что в этой ситуации лично меня радует - я не вижу никаких
> оснований для привлечения своей персоны как свидетеля по возможному "делу
> freenginx" :-)
> Тьфу-тьфу-тьфу.
Да ты, однако, оптимист! :))
Hello!
On Thu, Feb 15, 2024 at 04:31:49PM +0400, Roman Arutyunyan wrote:
> Hello,
>
> On Wed, Feb 14, 2024 at 08:59:10PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > As you probably know, F5 closed Moscow office in 2022, and I no
> > longer work for F5
Hello!
On Thu, Feb 15, 2024 at 04:49:10PM +0800, Archimedes Gaviola wrote:
> On Thu, Feb 15, 2024 at 2:03 AM Maxim Dounin wrote:
>
> > Hello!
> >
> > As you probably know, F5 closed Moscow office in 2022, and I no
> > longer work for F5 since then. Still, we’ve r
Hello!
On Thu, Feb 15, 2024 at 10:17:57AM +0300, Andrey Kopeyko wrote:
> Gena Makhomed писал 2024-02-15 04:17:
> > On 14.02.2024 19:59, Maxim Dounin wrote:
> >
> > > Подобный подход можно понять: они владеют проектом, и могут с ним
> > > делать всё, что
Will follow freenginx then.
> Thx.
Thanks.
Interesting term, never heard it before.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote:
> On 14.02.2024 19:59, Maxim Dounin wrote:
>
> > Подобный подход можно понять: они владеют проектом, и могут с ним
> > делать всё, что считают нужным, включая подобные маркетинговые
> > акции. Э
Hello!
On Thu, Feb 15, 2024 at 01:33:08AM +0300, Vasiliy Soshnikov wrote:
> Hello Maxim,
> Sad to read it. I can't promise that, but I will try to support your
> project by using freenginx at least.
> I wish good luck to freenginx!
Thanks, appreciated.
--
Maxim Dounin
http:
Hello!
On Wed, Feb 14, 2024 at 10:45:37PM +0100, Sergey Brester wrote:
> Hi Maxim,
>
> it is pity to hear such news...
>
> I have few comments and questions about, which I enclosed inline below...
>
> Regards,
> Serg.
>
> 14.02.2024 19:03, Maxim Dounin wrote:
myself.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Thu, Feb 15, 2024 at 03:24:59AM +0800, Jeffrey 'jf' Lim wrote:
> On Thu, Feb 15, 2024 at 1:59 AM Maxim Dounin wrote:
>
> > Hello!
> >
> > As you probably know, F5 closed Moscow office in 2022, and I no
> > longer work for F5 since then. Still, we’ve r
; Нет ли в планах поднять какой-нибудь небольшой форум?
Нет, и опять же нет. Продвижение особого смысла не имеет, проект
строго некоммерческий и не предполагает каких-либо коммерческих
перспектив. Что до форумов, то это совершенно не мой формат
общения.
--
Maxim Dounin
http://mdounin.ru/
_
://freenginx.org/
The goal is to keep nginx development free from arbitrary corporate
actions. Help and contributions are welcome. Hope it will be
beneficial for everyone.
--
Maxim Dounin
http://freenginx.org/
___
nginx-devel mailing list
nginx-devel
корпоративные структуры:
http://freenginx.org/
Цель проекта - обеспечить разработку nginx'а, свободную от
произвольного корпоративного вмешательства. Помощь и участие
приветствуются. Надеюсь, проект будет полезен для всех.
--
Maxim Dounin
http://freenginx.org
://freenginx.org/
The goal is to keep nginx development free from arbitrary corporate
actions. Help and contributions are welcome. Hope it will be
beneficial for everyone.
--
Maxim Dounin
http://freenginx.org/
___
nginx mailing list
nginx@nginx.org
en if there was an error or a timeout.
In contrast, $upstream_connect_time and $upstream_header_time are
only set when the connection was established or the header was
successfully received, respectively.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel
nd there is an FC byte instead. To
see what's there in fact, consider looking at the raw bytes in the
file name with something like "ls | hd".
Also, you can use nginx autoindex module - it will generate a page
with properly escaped links, so it will be possi
use
try_files, as simply serving static files is equivalent (unless
you specifically want to return 404 for directories).
That is, just
location /camp/ {
root "C:/.../clearwater";
}
would be (mostly) equivalent.
But, given that you want "/camp/camprental.pdf&qu
Hello!
On Tue, Feb 06, 2024 at 01:36:20PM +0100, Jan Prachař wrote:
> Hello,
>
> I have one last note bellow.
>
> On Tue, 2024-02-06 at 14:08 +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Tue, Feb 06, 2024 at 11:42:40AM +0100, Jan Prachař wrote:
> >
Hello!
On Tue, Feb 06, 2024 at 11:42:40AM +0100, Jan Prachař wrote:
> Hello Maxim,
>
> On Tue, 2024-02-06 at 00:46 +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Mon, Feb 05, 2024 at 06:01:54PM +0100, Jan Prachař wrote:
> >
> > > Hello,
оляет дополнительно и существенно снизить затраты
за счёт буферизации и даже gzip-сжатия на лету.
Если на выходе всё равно файлы - совершенно непонятно, зачем
нужна вся эта запись в python-скрипты, изображающие из себя
syslog-сервера.
[...]
-
Hello!
On Mon, Feb 05, 2024 at 06:01:54PM +0100, Jan Prachař wrote:
> Hello,
>
> thank you for your responses.
>
> On Sat, 2024-02-03 at 04:25 +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Fri, Feb 02, 2024 at 01:47:51PM +0100, Jan Prachař wrote:
>
какого, да и в самом curl'е относится только к случаю получения
нескольких файлов одновременно по одному соединению.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
0123456789abcdef0123456789abcdef0123456789abcdef
Since first 680 bytes of this "request" is actually the request body
of the previous request, the request line actually starts
somewhere in "0123456789abcdef0123..." bytes, and the method is
modules" under prefix, but you'll have
to use something different if you've modified --modules-path to a
custom value.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
ngx_http_request_
u->cache_status = NGX_HTTP_CACHE_STALE;
rc = ngx_http_upstream_cache_send(r, u);
-if (rc == NGX_DONE) {
-return;
-}
-
if (rc == NGX_HTTP_UPSTREAM_INVALID_HEADER) {
rc = NGX_HTTP_INTERNAL_SERVER_ERROR;
}
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
g "large number of regex server_names" might be the best
solution available here. Requests are not required to be to the
same virtual server, and caching won't generally work.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
. Removing
uncompressed files usually makes sense only if amount of static
files is huge.
Hope this helps.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
on_t *c,
> }
>
> curves = ngx_palloc(pool, n * sizeof(int));
> +if (curves == NULL) {
> +return NGX_ERROR;
> +}
>
> n = SSL_get1_curves(c->ssl->connection, curves);
> len = 0;
Looks good.
--
Maxim Dounin
http://mdounin.ru
Hello!
On Mon, Jan 29, 2024 at 05:21:43PM +0400, Sergey Kandaurov wrote:
>
> > On 29 Jan 2024, at 10:43, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Fri, Jan 26, 2024 at 04:26:00PM +0400, Sergey Kandaurov wrote:
> >
> >>> On 27 Nov 202
Hello!
On Mon, Jan 29, 2024 at 06:07:58PM +0400, Roman Arutyunyan wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 10:58:09AM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Fri, Jan 26, 2024 at 04:02:30PM +0400, Roman Arutyunyan wrote:
> >
> > > On Mo
Hello!
On Mon, Jan 29, 2024 at 05:23:15PM +0400, Sergey Kandaurov wrote:
> > On 29 Jan 2024, at 07:24, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Sat, Jan 27, 2024 at 07:19:45AM +0300, Maxim Dounin wrote:
> >
> >> Hello!
> >>
0 GMT
> # Content-Type: text/html
> # Content-Length: 215
> # Connection: close
> # X-Client: CN=end
> # X-Verify: FAILED:unsuitable certificate purpose
[...]
Should be fixed with this patch:
https://mailman.nginx.org/pipermail/nginx-devel/2024-January/TSFBB5DWWQKXKDTGVLSH5VWJYMRC
Hello!
On Fri, Jan 26, 2024 at 04:02:30PM +0400, Roman Arutyunyan wrote:
> On Mon, Nov 27, 2023 at 05:50:24AM +0300, Maxim Dounin wrote:
> > # HG changeset patch
> > # User Maxim Dounin
> > # Date 1701049682 -10800
> > # Mon Nov 27 04:48:
Hello!
On Fri, Jan 26, 2024 at 04:27:30PM +0400, Sergey Kandaurov wrote:
>
> > On 27 Nov 2023, at 06:50, Maxim Dounin wrote:
> >
> > # HG changeset patch
> > # User Maxim Dounin
> > # Date 1701050170 -10800
> > # Mon N
Hello!
On Fri, Jan 26, 2024 at 04:26:21PM +0400, Sergey Kandaurov wrote:
>
> > On 27 Nov 2023, at 06:50, Maxim Dounin wrote:
> >
> > # HG changeset patch
> > # User Maxim Dounin
> > # Date 1701049787 -10800
> > # Mon N
Hello!
On Fri, Jan 26, 2024 at 04:26:00PM +0400, Sergey Kandaurov wrote:
> > On 27 Nov 2023, at 06:50, Maxim Dounin wrote:
> >
> > # HG changeset patch
> > # User Maxim Dounin
> > # Date 1701049758 -10800
> > # Mon Nov
Hello!
On Sat, Jan 27, 2024 at 07:19:45AM +0300, Maxim Dounin wrote:
> Hello!
>
> On Fri, Jan 26, 2024 at 09:29:58PM +0400, Sergey Kandaurov wrote:
>
> > On Thu, Jan 25, 2024 at 11:38:57PM +0300, Maxim Dounin wrote:
> > > Hello!
> > >
> > > On Thu,
.
That's a result of incompatible change introduced in the
"openssl" application by OpenSSL 3.2.0, it now generates X509v3
certs even if not asked to, just discussed here:
https://mailman.nginx.org/pipermail/nginx-devel/2024-January/32O7PUI3XJZZGBMLS2NAH654MS23MVDD.html
Will be eventuall
Hello!
On Fri, Jan 26, 2024 at 09:29:58PM +0400, Sergey Kandaurov wrote:
> On Thu, Jan 25, 2024 at 11:38:57PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Thu, Jan 25, 2024 at 06:59:36PM +, Mayerhofer, Austin via
> > nginx-devel wrote:
> >
> >
ion in 2.2.
Message parsing of RFC 9112. And one less might also work, as
long as empty lines before the request-line accept bare LF (not
sure about Node though).
Overall, I don't think there is a big difference here.
> > including manual testing such
> > as with nc(1).
the case if, for example, Net::SSLeay in
your installation was compiled with system LibreSSL as an SSL
library - at least on the server side LibreSSL simply does not
support session reuse with TLSv1.3.
Test suite checks if nginx was compiled with LibreSSL and marks
ap
a lines, where
> the standard does not permit LF/CRLF permissiveness. It's also a
> delete-only patch, which is always nice :)
>
> If you all are open to this change, it will also be necessary to fix
> up the many LF-delimited chunks that are present within the test
> suite.
No, tha
rating SSLKEYLOGFILE on
> peer, or by using other hacks on nginx host (using GDB, or patched ssl
> libraries).
Thanks for the patch.
Logging session keying material is known to be problematic from
ethical point of view. As such, I would rather avoid introducing
nsure there are no real issues introduced by various compiler
optimizations.
[...]
> There is a proposal for C2y to define memcpy(NULL,NULL,0):
> https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UCPyZOTLsnRfR6UleD1F8/edit
> If you feel strongly that memcpy from NULL should be defi
* Redistribution and use in source and binary forms, with or without
> diff --git a/xml/menu.xml b/xml/menu.xml
> --- a/xml/menu.xml
> +++ b/xml/menu.xml
> @@ -59,6 +59,7 @@
> -->
>
> news
> +
>
>
>
Looks good.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
--git a/xml/ru/docs/index.xml b/xml/ru/docs/index.xml
> --- a/xml/ru/docs/index.xml
> +++ b/xml/ru/docs/index.xml
> @@ -8,7 +8,7 @@
> link="/ru/docs/"
> lang="ru"
> - rev="49"
> + rev="50"
> toc=&quo
Hello!
On Mon, Jan 22, 2024 at 07:48:01PM +0400, Roman Arutyunyan wrote:
> Hi,
>
> On Mon, Jan 22, 2024 at 02:59:21PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Mon, Jan 22, 2024 at 02:49:54PM +0400, Roman Arutyunyan wrote:
> >
> > > # HG cha
but not for others.
Wouldn't it be better to remember if the PROXY protocol was used
to set the address, and use $proxy_protocol_server_addr /
$proxy_protocol_server_port in this case?
Alternatively, we can use some dummy server address instead, so
the client address will be still sent.
--
Maxim Dou
Hello!
On Fri, Jan 19, 2024 at 03:42:37PM +0400, Sergey Kandaurov wrote:
>
> > On 18 Jan 2024, at 23:44, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Thu, Jan 18, 2024 at 08:15:33PM +0400, Sergey Kandaurov wrote:
> >
> >> On Thu, Jan 18,
+if (c->read->pending_eof) {
> > +return NGX_STREAM_OK;
> > +}
> > +
> > +c->buffer->last = c->buffer->pos;
> > +
> > +return NGX_AGAIN;
> > +}
> > +
> > +
> > +static ngx_int_t
> > +ngx_stream_preread(ngx_stream_session_t *s, ngx_stream_phase_handler_t *ph)
> > +{
> > +ssize_tn;
> > +ngx_int_t rc;
> > +ngx_connection_t *c;
> > +
> > +c = s->connection;
> > +
> > +while (c->read->ready) {
> > +
> > +n = c->recv(c, c->buffer->last, c->buffer->end - c->buffer->last);
> > +
> > +if (n == NGX_AGAIN) {
> > +return NGX_AGAIN;
> > +}
> > +
> > +if (n == NGX_ERROR || n == 0) {
> > +return NGX_STREAM_OK;
> > +}
> > +
> > +c->buffer->last += n;
> > +
> > +rc = ph->handler(s);
> > +
> > +if (rc != NGX_AGAIN) {
> > +return rc;
> > +}
> > +
> > +if (c->buffer->last == c->buffer->end) {
> > +ngx_log_error(NGX_LOG_ERR, c->log, 0, "preread buffer full");
> > +return NGX_STREAM_BAD_REQUEST;
> > +}
> > +}
> > +
> > +return NGX_AGAIN;
> > +}
> > +
> > +
> > ngx_int_t
> > ngx_stream_core_content_phase(ngx_stream_session_t *s,
> > ngx_stream_phase_handler_t *ph)
>
> Looks good.
I'm somewhat sceptical about the idea of functionality which
depends on the edge-triggered event methods being available.
If/when the patch series is reviewed, please make sure it gets my
approval before commit.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
ено, то в системе можно
настроить с помощью соответствующих sysctl'ей -
net.inet.udp.recvspace и net.local.dgram.recvspace для FreeBSD,
net.core.rmem_default (а при необходимости net.ipv4.udp_mem и
net.ipv4.udp_rmem_min) на Linux.
Для локальных сокетов на Linux'е, судя по всему, нужно ещё крутить
лучшить ситуацию - я бы начал с тюнинга буферов
сокета syslog-сервера.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
о он вообще сейчас не читает файлы кэша,
только составляет их список (до nginx 1.1.0 было по другому, но
с тех пор прошло уже больше 10 лет).
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
-Modified-Since, на которые nginx вернёт 304, и так далее.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
happens, the response
headers are already sent, so $status contains 200 as sent to the
client.
For errors happened during sending the response body, consider
looking into the error log. Some generic information about
successful request completion migh
happens, the response
headers are already sent, so $status contains 200 as sent to the
client.
For errors happened during sending the response body, consider
looking into the error log. Some generic information about
successful request completion migh
будет, так как ETag, полученный от исходного сервера, будет
сохранён вместе с заголовками ответа. (Ну а в случае proxy_store,
где заголовки не сохраняются, проблемы с будут с любыми кастомными
ETag'ами.)
--
Maxim Dounin
http://mdounin.ru/
___
nginx-
ли большие -
нужно использовать буфера соответствующего размера.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
452969#0: *11 access phase: 8
Note that phase handling continues here: it shouldn't, since
request body reading is in progress.
This suggested that your code fails to stop phase handling after
calling ngx_http_read_client_request_body(): note you should
return NGX_DONE to stop processing
м как с
портабельностью, так и с хранением/синхронизацией (e.g., в том же
nix store они могут просто не работать).
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Hello!
On Fri, Jan 12, 2024 at 11:03:45PM +, Jakub Zelenka wrote:
> On Fri, Jan 12, 2024 at 10:20 PM Maxim Dounin wrote:
>
> > > # HG changeset patch
> > > # User Jakub Zelenka
> > > # Date 1705078404 0
> > > # Fri
но, плохой вариант для нагруженного сервера, так
как файл придётся на каждый запрос читать дважды. А получать
hash-сумму откуда-то ещё, скажем из внешнего файла или
extended-атрибутов - выглядит в лучшем случае дополнительной фичей
(смотри https://trac.ngin
ll?
Access phase handlers are called for all requests (unless these
are rejected at earlier stages). If in doubt, consider configuring
debug logging and add appropriate debug logging to your module, it
should make things obvious enough.
--
Maxim Dounin
http://mdounin.ru/
port;
> +fastcgi_param REMOTE_HOST$host;
> fastcgi_param SERVER_ADDR$server_addr;
> fastcgi_param SERVER_PORT$server_port;
> fastcgi_param SERVER_NAME$server_name;
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
p_core_run_phases(). See here in the mirror module for an
example:
https://hg.nginx.org/nginx/file/tip/src/http/modules/ngx_http_mirror_module.c#l144
Hope this helps.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.o
o direct impact" situation as assumed
above. If you think there are cases when the code can be
miscompiled in practice, and not theoretically, please share.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Hello!
On Mon, Jan 08, 2024 at 01:31:11PM +, J Carter wrote:
> On Mon, 8 Jan 2024 11:25:55 +
> J Carter wrote:
>
> > Hello,
> >
> > On Mon, 27 Nov 2023 05:50:27 +0300
> > Maxim Dounin wrote:
> >
> > > # HG changeset patch
> >
Hello!
On Tue, Dec 26, 2023 at 12:29:54AM +0400, Sergey Kandaurov wrote:
> > On 23 Dec 2023, at 01:46, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Fri, Dec 22, 2023 at 06:28:34PM +0400, Sergey Kandaurov wrote:
> >
> >> # HG changeset pa
ожно пытаться в ETag вставлять какой-то
идентификатор представления, то если для gzip_static добавлять в
ETag что-нибудь вроде "...-gz". Но при наличии размера в том же
ETag'е смысла в этом исчезающие мало.
--
Maxim Dounin
http://mdounin.ru/
_
ло быстро - надо выносить (большую) статику в
отдельный домен, где разрешать только HTTP/1.x, и соответственно
включать sendfile и kTLS.
Впрочем, насколько быстро - это отдельный вопрос. Скорее всего на
линуксе примерно те же результаты можно получить
response to the
POST request itself (this is generally a bad practice, since it
will break page refresh and browser history navigation), consider
returning the file directly from your script instead of trying to
do an internal redirect.
--
Maxim Dounin
http://mdounin.ru/
roxy_ssl on;" to handle SSL/TLS with the backend
servers for you, see http://nginx.org/r/proxy_ssl for details.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
ственно
влияния на производительность HTTP/3 от включения kTLS не будет.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
debase, and at least some need
serious audit to find out if { 0, NULL } can appear in the call,
this is going to be a huge work. And, given that the only
expected effect is theoretical correctness of the code, I doubt it
worth the effort, especially given that the end resu
ndows.html). Its main purpose is to
facilitate web development directly on Windows devices.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
ine functions here, and I think a solution with inline
functions can be accepted provided it is demonstrated that it
introduces no measurable performance degradation.
Still, I'm very sceptical about the idea of "transitioning away
from function-like macros".
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
of requests per day from a legitimate user.
Note well that using "nodelay" (or "delay=N") is recommended with
such approach, see http://nginx.org/r/limit_req for details.
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Thu, Dec 28, 2023 at 05:23:38PM +0300, Vladimir Homutov via nginx-devel
wrote:
> On Thu, Dec 28, 2023 at 04:31:41PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Wed, Dec 27, 2023 at 04:17:38PM +0300, Vladimir Homutov via nginx-devel
> > wrote:
> >
нфиг, так как из чего-то вроде:
server { listen 443 ssl http2; server_name foo; ... }
server { listen 443; server_name bar; ... }
где HTTP/2 работает в обоих блоках server, получится конфигурация
вида:
server { listen 443 ssl; http2 on; server_name foo; ... }
ть.
Подробнее в коммит-логе тут:
https://hg.nginx.org/nginx/rev/08ef02ad5c54
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Hello!
On Wed, Dec 27, 2023 at 04:17:38PM +0300, Vladimir Homutov via nginx-devel
wrote:
> On Wed, Dec 27, 2023 at 02:48:04PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Mon, Dec 25, 2023 at 07:52:41PM +0300, Vladimir Homutov via nginx-devel
> > wrote
nx started sending the response. It's a one-time choice, and
modifications of r->upstream->buffering won't do anything (though
also incorrect, as it's not something expected to be modified by
modules).
Or I understood something incorrectly?
--
Maxim Dounin
http://mdounin.ru/
__
tain plans to make proxy module able to
work with other protocols based on the scheme, such as in
"proxy_pass fastcgi://127.0.0.1:9000;". This is mostly irrelevant
though, and might never happen.)
[...]
--
Maxim Dounin
http://mdounin.ru/
___
m;
r->write_event_handler =
ngx_http_upstream_process_non_buffered_downstream;
r->limit_rate = 0;
r->limit_rate_set = 1;
(https://hg.nginx.org/nginx/file/release-1.25.3/src/http/ngx_http_upstream.c#l3092
Hello!
On Fri, Dec 22, 2023 at 05:53:30PM +0400, Sergey Kandaurov wrote:
>
> > On 21 Dec 2023, at 02:40, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Tue, Dec 19, 2023 at 10:44:00PM +0400, Sergey Kandaurov wrote:
> >
> >>
>
only justification I
can assume here is an SSL session with the client certificate (or
even certificate chain) being saved into the session. It might
worth looking into what actually happens here.
[...]
--
Maxim Dounin
http://mdounin.ru/
___
ngin
Hello!
On Fri, Dec 22, 2023 at 05:52:30PM +0400, Sergey Kandaurov wrote:
> On Thu, Dec 21, 2023 at 07:14:40PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Thu, Dec 21, 2023 at 05:37:02PM +0400, Sergey Kandaurov wrote:
> >
> > > > On 16
from nginx.org without any 3rd party modules and/or patches and
testing if you are able to reproduce the problem.
[...]
--
Maxim Dounin
http://mdounin.ru/
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Thu, Dec 21, 2023 at 05:37:02PM +0400, Sergey Kandaurov wrote:
> > On 16 Dec 2023, at 06:57, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Sat, Dec 09, 2023 at 08:42:11AM +, J Carter wrote:
> >
> >> On Sat, 09 Dec 2023 07:46:10
This will work with proxying without request buffering,
but will be generally more complex to implement. And, obviously,
this in case of proxying without request buffering this won't let
you to validate request body before the request headers are sent
to upstream server
with doing something like "ngx_max(foo & 0xff, bar)".
As such, it's certainly not an argument against using checks in
macro definitions in the particular patch.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Hello!
On Tue, Dec 19, 2023 at 10:44:00PM +0400, Sergey Kandaurov wrote:
>
> > On 19 Dec 2023, at 12:58, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Tue, Dec 19, 2023 at 02:09:10AM +0400, Sergey Kandaurov wrote:
> >
> >>> On 24 Nov 2023,
Hello!
On Tue, Dec 19, 2023 at 12:16:58PM +0100, Илья Шипицин wrote:
> вт, 19 дек. 2023 г. в 09:58, Maxim Dounin :
>
> > Hello!
> >
> > On Tue, Dec 19, 2023 at 02:09:10AM +0400, Sergey Kandaurov wrote:
> >
> > > > On 24 Nov 2023, at 00:29, Ilya Shipit
rt):
: Determines whether the connection with a proxied server should
: be closed when a client closes the connection without waiting for
: a response.
While it probably can be improved, it explicitly says "without
waiting for a response", and nothing about "when reading a
respons
might
be seen as positive even without any additional benefits.
Along with that, however, we might want to adjust the
LIBRESSL_VERSION_NUMBER check in the ngx_event_openssl.h file, so
OPENSSL_VERSION_NUMBER is set to a better value for old LibreSSL
versions - for example, to only set OPENSSL_VERSION_NUMBER to
0x101fL for LibreSSL 3.5.0 or above. This might allow to
preserve limited compatibility with ancient LibreSSL versions
without additional efforts (not tested though).
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
nitizer reports about
memcpy(dst, NULL, 0) in nginx" we might consider actually
silencing this by introducing appropriate checks at the interface
level.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
1 - 100 of 7336 matches
Mail list logo
