From mdounin at mdounin.ru  Sat Jul  1 00:43:57 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 1 Jul 2023 03:43:57 +0300
Subject: Possible bug with "proxy_intercept_errors on; " + "error_page
 301 302"?
In-Reply-To: <CAPdLF5wjqxS7PrnjAqEKwGArCZt+ePqMG2ZXgobR_PckAm=60g@mail.gmail.com>
References: <CAPdLF5xLaxOMBz-moERsVYHALf+A+TeMs+1ffa9u0YYZpQYg5g@mail.gmail.com>
 <ZJ3+5EpauwVrU+bG@mdounin.ru>
 <CAPdLF5wjqxS7PrnjAqEKwGArCZt+ePqMG2ZXgobR_PckAm=60g@mail.gmail.com>
Message-ID: <ZJ92zSAqvirZ0B98@mdounin.ru>

Hello!

On Fri, Jun 30, 2023 at 01:24:18PM -0300, Fabiano Furtado Pessoa Coelho wrote:

> Hello Maxim...
> 
> On Thu, Jun 29, 2023 at 7:00 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > Hello!
> >
> > On Thu, Jun 29, 2023 at 04:29:39PM -0300, Fabiano Furtado Pessoa Coelho wrote:
> >
> > > Hi...
> ...
> > > "proxy_intercept_errors on;"?
> >
> > The "proxy_intercept_errors" handling does not copy any response
> > headers from the original response (the only exception is
> > WWW-Authenticate for 403 responses).
> >
> > If you want nginx to copy some headers, consider doing it yourself
> > with the $upstream_http_* variables and the add_header directive.
> > Something like this should work:
> >
> >     location /30x.html {
> >         add_header Location $upstream_http_location;
> >         ...
> >     }
> >
> > Note though that you'll have to manually rewrite location if
> > needed (as proxy_redirect handling won't be used).
> 
> Your approach worked fine for me! Thanks for the help.
> 
> Horever, without this "add_header" modification and with
> "proxy_intercept_errors on;", I've two situations:
> * without "error_page 301 302 /30x.html;" directive configured: I
> receive the HTTP "location" header from my NGINX;
> * with "error_page 301 302 /30x.html;" directive configured: I don't
> receive the HTTP "location" header from my NGINX;
> 
> If "proxy_intercept_errors" handling does not copy any response
> headers from the original response, why is this HTTP "location" header
> present with "error_page 301 302 /30x.html;" directive configured in
> my system?
> 
> I really don't understand why it happens.

The "proxy_intercept_errors" directive only works for error 
responses for which you have an error_page explicitly configured.  
That is:

- If you don't have an error_page configured for the particular 
  response code, nginx returns the original response as obtained 
  from the upstream server, with all the response headers, much like 
  it does with "proxy_intercept_errors off;".

- If you do have an error_page configured, nginx instead 
  intercepts the error as per "proxy_intercept_errors on;", and 
  returns the error page to the client.  This response does not contain
  headers from the original response.

This seems to be exactly what you are seeing (assuming "with" in 
your final question is a typo, and you mean "without" instead).  
Hope this helps.

-- 
Maxim Dounin
http://mdounin.ru/

From fusca14 at gmail.com  Sat Jul  1 01:15:45 2023
From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho)
Date: Fri, 30 Jun 2023 22:15:45 -0300
Subject: Possible bug with "proxy_intercept_errors on;
 " + "error_page 301 302"?
In-Reply-To: <ZJ92zSAqvirZ0B98@mdounin.ru>
References: <CAPdLF5xLaxOMBz-moERsVYHALf+A+TeMs+1ffa9u0YYZpQYg5g@mail.gmail.com>
 <ZJ3+5EpauwVrU+bG@mdounin.ru>
 <CAPdLF5wjqxS7PrnjAqEKwGArCZt+ePqMG2ZXgobR_PckAm=60g@mail.gmail.com>
 <ZJ92zSAqvirZ0B98@mdounin.ru>
Message-ID: <CAPdLF5y0bNizD7ucL-yg-vALmQXnna-HYstqqdsyMcryU7oNZw@mail.gmail.com>

Thanks.

On Fri, Jun 30, 2023, 9:44 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Fri, Jun 30, 2023 at 01:24:18PM -0300, Fabiano Furtado Pessoa Coelho
> wrote:
>
> > Hello Maxim...
> >
> > On Thu, Jun 29, 2023 at 7:00 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > >
> > > Hello!
> > >
> > > On Thu, Jun 29, 2023 at 04:29:39PM -0300, Fabiano Furtado Pessoa
> Coelho wrote:
> > >
> > > > Hi...
> > ...
> > > > "proxy_intercept_errors on;"?
> > >
> > > The "proxy_intercept_errors" handling does not copy any response
> > > headers from the original response (the only exception is
> > > WWW-Authenticate for 403 responses).
> > >
> > > If you want nginx to copy some headers, consider doing it yourself
> > > with the $upstream_http_* variables and the add_header directive.
> > > Something like this should work:
> > >
> > >     location /30x.html {
> > >         add_header Location $upstream_http_location;
> > >         ...
> > >     }
> > >
> > > Note though that you'll have to manually rewrite location if
> > > needed (as proxy_redirect handling won't be used).
> >
> > Your approach worked fine for me! Thanks for the help.
> >
> > Horever, without this "add_header" modification and with
> > "proxy_intercept_errors on;", I've two situations:
> > * without "error_page 301 302 /30x.html;" directive configured: I
> > receive the HTTP "location" header from my NGINX;
> > * with "error_page 301 302 /30x.html;" directive configured: I don't
> > receive the HTTP "location" header from my NGINX;
> >
> > If "proxy_intercept_errors" handling does not copy any response
> > headers from the original response, why is this HTTP "location" header
> > present with "error_page 301 302 /30x.html;" directive configured in
> > my system?
> >
> > I really don't understand why it happens.
>
> The "proxy_intercept_errors" directive only works for error
> responses for which you have an error_page explicitly configured.
> That is:
>
> - If you don't have an error_page configured for the particular
>   response code, nginx returns the original response as obtained
>   from the upstream server, with all the response headers, much like
>   it does with "proxy_intercept_errors off;".
>
> - If you do have an error_page configured, nginx instead
>   intercepts the error as per "proxy_intercept_errors on;", and
>   returns the error page to the client.  This response does not contain
>   headers from the original response.
>
> This seems to be exactly what you are seeing (assuming "with" in
> your final question is a typo, and you mean "without" instead).
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230630/e03183db/attachment.htm>

From xeioex at nginx.com  Thu Jul  6 22:23:22 2023
From: xeioex at nginx.com (Dmitry Volyntsev)
Date: Thu, 6 Jul 2023 15:23:22 -0700
Subject: njs-0.8.0
Message-ID: <9c724659-4a8e-7298-bc66-885093b09790@nginx.com>

Hello,

I'm glad to announce a new release of NGINX JavaScript module (njs).

Notable new features:
- shared dictionaries:
Shared dictionary keeps the key-value pairs shared between worker
processes. This allows to cache data in memory and share it between
workers.

: example.conf:
:   # Creates a 1Mb dictionary with string values,
:   # removes key-value pairs after 60 seconds of inactivity:
:   js_shared_dict_zone zone=foo:1M timeout=60s;
:
:   # Creates a 512Kb dictionary with string values,
:   # forcibly removes oldest key-value pairs when the zone is overflowed:
:   js_shared_dict_zone zone=bar:512K timeout=30s evict;
:
:   # Creates a 32Kb permanent dictionary with numeric values:
:   js_shared_dict_zone zone=num:32k type=number;
:
: example.js:
:    function get(r) {
:        r.return(200, ngx.shared.foo.get(r.args.key));
:    }
:
:    function set(r) {
:        r.return(200, ngx.shared.foo.set(r.args.key, r.args.value));
:    }
:
:    function delete(r) {
:        r.return(200, ngx.shared.bar.delete(r.args.key));
:    }
:
:    function increment(r) {
:        r.return(200, ngx.shared.num.incr(r.args.key, 2));
:    }

Learn more about njs:

- Overview and introduction:
      https://nginx.org/en/docs/njs/
- NGINX JavaScript in Your Web Server Configuration:
      https://youtu.be/Jc_L6UffFOs
- Extending NGINX with Custom Code:
      https://youtu.be/0CVhq4AUU7M
- Using node modules with njs:
      https://nginx.org/en/docs/njs/node_modules.html
- Writing njs code using TypeScript definition files:
      https://nginx.org/en/docs/njs/typescript.html

Feel free to try it and give us feedback on:

- Github:
      https://github.com/nginx/njs/issues
- Mailing list:
      https://mailman.nginx.org/mailman/listinfo/nginx-devel

Additional examples and howtos can be found here:

- Github:
      https://github.com/nginx/njs-examples

Changes with njs 0.8.0                                        6 Jul 2023

     nginx modules:

     *) Change: removed special treatment of forbidden headers in Fetch API
        introduced in 0.7.10.

     *) Change: removed deprecated since 0.5.0 r.requestBody and
        r.responseBody in HTTP module.

     *) Change: throwing an exception in r.internalRedirect() while
        filtering in HTTP module.

     *) Feature: introduced global nginx properties.
         ngx.build - an optional nginx build name, corresponds to
         --build=name argument of configure script, by default is "".
         ngx.conf_file_path - the file path to current nginx configuration
             file.
         ngx.error_log_path - the file path to current error log file.
         ngx.prefix - the directory that keeps server files.
         ngx.version - the nginx version as a string, for example: "1.25.0".
         ngx.version_number - the nginx version as a number, for example:
             1025000.
         ngx.worker_id - corresponds to an nginx internal worker id.
            The value is between 0 and worker_processes - 1.

     *) Feature: introduced js_shared_dict_zone directive.
         The directive allows to declare a dictionary that is shared 
among the
         working processes.

     *) Improvement: added compile-time options to disable njs modules.
         For example to disable libxslt related code:
         NJS_LIBXSLT=NO ./configure  .. --add-module=/path/to/njs/module

     *) Bugfix: fixed r.status setter when filtering in HTTP module.

     *) Bugfix: fixed setting of Location header in HTTP module.

     Core:

     *) Change: native methods are provided with retval argument.
        This change breaks compatibility with C extension for njs
        requiring to modify the code.

     *) Change: non-compliant deprecated String methods were removed.
         The following methods were removed: String.bytesFrom(),
         String.prototype.fromBytes(), String.prototype.fromUTF8(),
         String.prototype.toBytes(), String.prototype.toUTF8(),
         String.prototype.toString(encoding).

     *) Change: removed support for building with GNU readline.

     *) Feature: added Array.from(), Array.prototype.toSorted(),
         Array.prototype.toSpliced(), Array.prototype.toReversed().

     *) Feature: added %TypedArray%.prototype.toSorted(),
         %TypedArray%.prototype.toSpliced(),
         %TypedArray%.prototype.toReversed().

     *) Feature: added CryptoKey properties in WebCrypto.
         The following properties for CryptoKey were added:
         algorithm, extractable, type, usages.

     *) Bugfix: fixed retval of crypto.getRandomValues().

     *) Bugfix: fixed evaluation of computed property names with function
        expressions.

     *) Bugfix: fixed implicit name for a function expression declared in
        arrays.

     *) Bugfix: fixed parsing of for-in loops.

     *) Bugfix: fixed Date.parse() with ISO-8601 format and UTC time
        offset.

From maxim at nginx.com  Fri Jul  7 01:50:28 2023
From: maxim at nginx.com (Maxim Konovalov)
Date: Thu, 6 Jul 2023 18:50:28 -0700
Subject: njs-0.8.0
In-Reply-To: <9c724659-4a8e-7298-bc66-885093b09790@nginx.com>
References: <9c724659-4a8e-7298-bc66-885093b09790@nginx.com>
Message-ID: <7d2ccf47-171a-d003-0dcd-052c3a9327de@nginx.com>

On 06.07.2023 15:23, Dmitry Volyntsev wrote:
> Hello,
> 
> I'm glad to announce a new release of NGINX JavaScript module (njs).
> 
> Notable new features:
> - shared dictionaries:
> Shared dictionary keeps the key-value pairs shared between worker
> processes. This allows to cache data in memory and share it between
> workers.
> 
This is big.

Congrats, Dima and team.

Maxim


-- 
Maxim Konovalov

From francis at daoine.org  Sun Jul  9 23:09:22 2023
From: francis at daoine.org (Francis Daly)
Date: Mon, 10 Jul 2023 00:09:22 +0100
Subject: Mixing limit_except breaks rewrite functionality: workaround
 request
In-Reply-To: <CAFg95JUX48suFmm+X3G1Tve8GBscK9NHNs7hANo=sLZsLVzhUw@mail.gmail.com>
References: <CAFg95JUX48suFmm+X3G1Tve8GBscK9NHNs7hANo=sLZsLVzhUw@mail.gmail.com>
Message-ID: <20230709230922.GB6038@daoine.org>

On Fri, Jun 30, 2023 at 11:29:21AM +0200, Sten Gruener wrote:

Hi there,

> I trying to mix authentication for POST requests with some
> rewrite/proxy_pass logic. This mean that password is required only on
> POST/PUT requests.

This does not answer the question you asked, but is there a reason for
the "rewrite, rewrite, return, proxy_pass" sequence instead of just
using exactly "proxy_pass http://server:8081/;"

It looks like that should do what you want, so bugs in the handling of
more complicated configs would not apply.

Thanks,

	f
-- 
Francis Daly        francis at daoine.org

From sten.gruener at gmail.com  Mon Jul 10 04:27:04 2023
From: sten.gruener at gmail.com (=?utf-8?Q?Sten_Gr=C3=BCner?=)
Date: Mon, 10 Jul 2023 06:27:04 +0200
Subject: Mixing limit_except breaks rewrite functionality: workaround
 request
In-Reply-To: <20230709230922.GB6038@daoine.org>
References: <20230709230922.GB6038@daoine.org>
Message-ID: <B23B8731-8E76-441D-B943-A8132AFD2EDA@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230710/2b642127/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon at 2.png
Type: image/png
Size: 6562 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230710/2b642127/attachment.png>

From francis at daoine.org  Mon Jul 10 15:41:48 2023
From: francis at daoine.org (Francis Daly)
Date: Mon, 10 Jul 2023 16:41:48 +0100
Subject: Mixing limit_except breaks rewrite functionality: workaround
 request
In-Reply-To: <B23B8731-8E76-441D-B943-A8132AFD2EDA@gmail.com>
References: <20230709230922.GB6038@daoine.org>
 <B23B8731-8E76-441D-B943-A8132AFD2EDA@gmail.com>
Message-ID: <20230710154148.GC6038@daoine.org>

On Mon, Jul 10, 2023 at 06:27:04AM +0200, Sten Grüner wrote:

Hi there,

>   Got to do rewrites, since otherwise nginx breaks urlencoded query
>   parameters.

Yes, that sounds like a good reason to not just use "the obvious" config.

So -- following the example in the trac ticket that you linked, doing something like

===
http {
    map $request_uri $request_without_x {
        ~^/x/(.*) $1;
        default "";
    }

...

    server {
...
        location /x/ {
            limit_except GET OPTIONS {
                auth_basic "Write Access";
                auth_basic_user_file /etc/nginx/conf.d/htpasswd_write;
            }
            proxy_pass http://server:8081/$request_without_x;
        }
    }
}
===

looks like it should do what you want?

Cheers,

	f
-- 
Francis Daly        francis at daoine.org

From fusca14 at gmail.com  Wed Jul 12 21:40:21 2023
From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho)
Date: Wed, 12 Jul 2023 18:40:21 -0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
Message-ID: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>

Hello...

I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".

Therefore, the "load_module" directive is not reading the path/config
specified in "--modules-path" parameter. For instance, in nginx.conf,
I have declared "load_module ngx_http_module1.so;" and when I test it,
the following message appears:
# nginx -t
nginx: [emerg] dlopen() "/etc/nginx/ngx_http_module1.so" failed
(/etc/nginx/ngx_http_module1.so: cannot open shared object file: No
such file or directory) in /etc/nginx/nginx.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed

Why? Should the "load_module" directive read "--modules-path" value,
if specified in "./configure"? From the "load_module" official
documentation (http://nginx.org/en/docs/ngx_core_module.html#load_module),
there is no default value defined, but, once "--modules-path" is
configured, the "load_module" directive should read from
"--modules-path", right? If not, what is the purpose of "./configure
... --modules-path=<path> ...", to compile NGINX?

Of course, if I specify the full path "load_module
/<path>/ngx_http_module1.so;", it works fine.

Thanks in advance.
Fabiano Furtado

From mdounin at mdounin.ru  Thu Jul 13 00:36:50 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 13 Jul 2023 03:36:50 +0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
Message-ID: <ZK9HIn0Ncem/oBHe@mdounin.ru>

Hello!

On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:

> Hello...
> 
> I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".
> 
> Therefore, the "load_module" directive is not reading the path/config
> specified in "--modules-path" parameter. For instance, in nginx.conf,
> I have declared "load_module ngx_http_module1.so;" and when I test it,
> the following message appears:
> # nginx -t
> nginx: [emerg] dlopen() "/etc/nginx/ngx_http_module1.so" failed
> (/etc/nginx/ngx_http_module1.so: cannot open shared object file: No
> such file or directory) in /etc/nginx/nginx.conf:12
> nginx: configuration file /etc/nginx/nginx.conf test failed
> 
> Why? Should the "load_module" directive read "--modules-path" value,
> if specified in "./configure"? From the "load_module" official
> documentation (http://nginx.org/en/docs/ngx_core_module.html#load_module),
> there is no default value defined, but, once "--modules-path" is
> configured, the "load_module" directive should read from
> "--modules-path", right? If not, what is the purpose of "./configure
> ... --modules-path=<path> ...", to compile NGINX?
> 
> Of course, if I specify the full path "load_module
> /<path>/ngx_http_module1.so;", it works fine.

The "--modules-path" configure option defines a directory where 
dynamic modules will be installed by "make install" and only used 
during installation.

The "load_module" configuration directive, if used with relative 
paths, resolves such paths from "--prefix", much like most of the 
configuration directives.  Note the example in the documentation 
(http://nginx.org/r/load_module):

    load_module modules/ngx_mail_module.so;

This example assumes the default "--modules-path", so modules are 
installed into the "modules" directory under prefix.

-- 
Maxim Dounin
http://mdounin.ru/

From osa at freebsd.org.ru  Thu Jul 13 00:38:22 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Thu, 13 Jul 2023 03:38:22 +0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
Message-ID: <ZK9HfhgXFpA0Y41f@FreeBSD.org.ru>

Hi Fabiano,

hope you're doing well.

On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:
> 
> I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".

The --modules-patch=<path> configure option defines a directory where
nginx dynamic modules will be installed, [1].

> Therefore, the "load_module" directive is not reading the path/config
> specified in "--modules-path" parameter.

The load_module directive, [2] utilizes a value of the --prefix configure
option, [1] as a relative path to the modules directory.  An authentic
package on a linux operating system creates a symlink with the source
/usr/lib/nginx/modules directory and the /etc/nginx/modules target.
In that case it's easy to use

load_module modules/ngx_http_module_1.so;

to load a dynamic module.

References
1. https://nginx.org/en/docs/configure.html
2. https://nginx.org/en/docs/ngx_core_module.html#load_module

Thank you.

-- 
Sergey A. Osokin

From fusca14 at gmail.com  Thu Jul 13 18:08:19 2023
From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho)
Date: Thu, 13 Jul 2023 15:08:19 -0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <ZK9HIn0Ncem/oBHe@mdounin.ru>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
 <ZK9HIn0Ncem/oBHe@mdounin.ru>
Message-ID: <CAPdLF5ySyi1FXAasoaCaFTMLGXh-djLPZgCimyY2daG6JTxN3w@mail.gmail.com>

Hello...

On Wed, Jul 12, 2023 at 9:37 PM Maxim Dounin wrote:
>
> Hello!
>
> On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:
>
> > Hello...
> >
> > I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".
> >
...
> > /<path>/ngx_http_module1.so;", it works fine.
>
> The "--modules-path" configure option defines a directory where
> dynamic modules will be installed by "make install" and only used
> during installation.
>
> The "load_module" configuration directive, if used with relative
> paths, resolves such paths from "--prefix", much like most of the
> configuration directives.  Note the example in the documentation
> (http://nginx.org/r/load_module):
>
>     load_module modules/ngx_mail_module.so;
>
> This example assumes the default "--modules-path", so modules are
> installed into the "modules" directory under prefix.

First of all, thanks for the help.

Is it a good idea to modify the "load_module" directive to read the
"--modules-path" parameter, if defined by "./configure", to use a
custom relative path instead of default "--prefix" relative path?

Thanks in advance.
Fabiano Furtado

From fusca14 at gmail.com  Thu Jul 13 18:09:03 2023
From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho)
Date: Thu, 13 Jul 2023 15:09:03 -0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <ZK9HfhgXFpA0Y41f@FreeBSD.org.ru>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
 <ZK9HfhgXFpA0Y41f@FreeBSD.org.ru>
Message-ID: <CAPdLF5yCOMnvj-K0r2hnSB6Y+dry0g9T4H-y9u-09Dk0BK==Zg@mail.gmail.com>

Thanks for the help, Sergey!

On Wed, Jul 12, 2023 at 9:38 PM Sergey A. Osokin wrote:
>
> Hi Fabiano,
>
> hope you're doing well.
>
> On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:
> >
> > I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".
>
> The --modules-patch=<path> configure option defines a directory where
> nginx dynamic modules will be installed, [1].
>
> > Therefore, the "load_module" directive is not reading the path/config
> > specified in "--modules-path" parameter.
>
> The load_module directive, [2] utilizes a value of the --prefix configure
> option, [1] as a relative path to the modules directory.  An authentic
> package on a linux operating system creates a symlink with the source
> /usr/lib/nginx/modules directory and the /etc/nginx/modules target.
> In that case it's easy to use
>
> load_module modules/ngx_http_module_1.so;
>
> to load a dynamic module.
>
> References
> 1. https://nginx.org/en/docs/configure.html
> 2. https://nginx.org/en/docs/ngx_core_module.html#load_module
>
> Thank you.
>
> --
> Sergey A. Osokin

From 4slam at mythicflow.com  Thu Jul 13 20:26:19 2023
From: 4slam at mythicflow.com (aslamK)
Date: Thu, 13 Jul 2023 20:26:19 +0000
Subject: Ubuntu repo update warns about skipping i386 packages on amd64
 machine.
Message-ID: <79f7d182-d75e-90b3-b26a-662000c21263@mythicflow.com>

In Ubuntu 22.04 (amd64), 'apt update' reports the following:

N:

Skipping acquire of configured file 'nginx/binary-i386/Packages'
as repository '
http://nginx.org/packages/u
buntu jammy InRelease'
doesn't support architecture 'i386'

To add the repo, I followed the directions at
http://nginx.org/en/linux_packages.html#Ubuntu
.

I realize it's only a warning and likely can be safely ignored,
at least on amd64 machines. If so, perhaps it can be suppressed
based on the architecture – unless this has to do with the local
apt config, in which case what are the relevant groups/options/values?

--
aslamK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230713/9c32ec6a/attachment.htm>

From thresh at nginx.com  Fri Jul 14 03:40:25 2023
From: thresh at nginx.com (Konstantin Pavlov)
Date: Thu, 13 Jul 2023 20:40:25 -0700
Subject: Ubuntu repo update warns about skipping i386 packages on amd64
 machine.
In-Reply-To: <79f7d182-d75e-90b3-b26a-662000c21263@mythicflow.com>
References: <79f7d182-d75e-90b3-b26a-662000c21263@mythicflow.com>
Message-ID: <272fed1d-302a-154b-d286-f5ffa8e484a1@nginx.com>

Hi aslamK!

On 13/07/2023 1:26 PM, aslamK wrote:
> In Ubuntu 22.04 (amd64), 'apt update' reports the following: N: 
> Skipping acquire of configured file 'nginx/binary-i386/Packages' as 
> repository 'http://nginx.org/packages/ubuntu jammy InRelease' doesn't 
> support architecture 'i386' To add the repo, I followed the directions 
> at http://nginx.org/en/linux_packages.html#Ubuntu. I realize it's only 
> a warning and likely can be safely ignored, at least on amd64 
> machines. If so, perhaps it can be suppressed based on the 
> architecture – unless this has to do with the local apt config, in 
> which case what are the relevant groups/options/values?

Looks like you have a foreign dpkg architecture enabled (i386) on an 
amd64 host.  You may check it with `dpkg --print-foreign-architectures`.

If that's true, you can add arch=amd64 to sources.d/nginx.list options, 
so it will look similar to:

deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] 
http://nginx.org/packages/ubuntu jammy nginx

Have a good one,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230713/e59f2044/attachment.htm>

From mdounin at mdounin.ru  Fri Jul 14 15:33:39 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 14 Jul 2023 18:33:39 +0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <CAPdLF5ySyi1FXAasoaCaFTMLGXh-djLPZgCimyY2daG6JTxN3w@mail.gmail.com>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
 <ZK9HIn0Ncem/oBHe@mdounin.ru>
 <CAPdLF5ySyi1FXAasoaCaFTMLGXh-djLPZgCimyY2daG6JTxN3w@mail.gmail.com>
Message-ID: <ZLFq0xh7du3QEWDL@mdounin.ru>

Hello!

On Thu, Jul 13, 2023 at 03:08:19PM -0300, Fabiano Furtado Pessoa Coelho wrote:

> Hello...
> 
> On Wed, Jul 12, 2023 at 9:37 PM Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:
> >
> > > Hello...
> > >
> > > I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".
> > >
> ...
> > > /<path>/ngx_http_module1.so;", it works fine.
> >
> > The "--modules-path" configure option defines a directory where
> > dynamic modules will be installed by "make install" and only used
> > during installation.
> >
> > The "load_module" configuration directive, if used with relative
> > paths, resolves such paths from "--prefix", much like most of the
> > configuration directives.  Note the example in the documentation
> > (http://nginx.org/r/load_module):
> >
> >     load_module modules/ngx_mail_module.so;
> >
> > This example assumes the default "--modules-path", so modules are
> > installed into the "modules" directory under prefix.
> 
> First of all, thanks for the help.
> 
> Is it a good idea to modify the "load_module" directive to read the
> "--modules-path" parameter, if defined by "./configure", to use a
> custom relative path instead of default "--prefix" relative path?

No, adding yet another option to resolve relative paths in 
configuration looks like a bad idea to me.  Resolving these from 
prefix looks perfectly correct and expected.

-- 
Maxim Dounin
http://mdounin.ru/

From fusca14 at gmail.com  Fri Jul 14 15:37:05 2023
From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho)
Date: Fri, 14 Jul 2023 12:37:05 -0300
Subject: load_module with "./configure ... --modules-path=<path> ..."
In-Reply-To: <ZLFq0xh7du3QEWDL@mdounin.ru>
References: <CAPdLF5yyrm=y2AOm2dRhiQ6JAN7MPBTge-5rr=dR4DWDdzg6fA@mail.gmail.com>
 <ZK9HIn0Ncem/oBHe@mdounin.ru>
 <CAPdLF5ySyi1FXAasoaCaFTMLGXh-djLPZgCimyY2daG6JTxN3w@mail.gmail.com>
 <ZLFq0xh7du3QEWDL@mdounin.ru>
Message-ID: <CAPdLF5wXoD26i53EdXQfW1hKgCZJS1KtbmaJr775fPp0vv-iGg@mail.gmail.com>

Hello...

On Fri, Jul 14, 2023 at 12:33 PM Maxim Dounin wrote:
>
> Hello!
>
> On Thu, Jul 13, 2023 at 03:08:19PM -0300, Fabiano Furtado Pessoa Coelho wrote:
>
> > Hello...
> >
> > On Wed, Jul 12, 2023 at 9:37 PM Maxim Dounin wrote:
> > >
> > > Hello!
> > >
> > > On Wed, Jul 12, 2023 at 06:40:21PM -0300, Fabiano Furtado Pessoa Coelho wrote:
> > >
> > > > Hello...
> > > >
> > > > I have compiled NGINX 1.24.0 with "./configure ... --modules-path=<path> ...".
> > > >
...
> > > This example assumes the default "--modules-path", so modules are
> > > installed into the "modules" directory under prefix.
> >
> > First of all, thanks for the help.
> >
> > Is it a good idea to modify the "load_module" directive to read the
> > "--modules-path" parameter, if defined by "./configure", to use a
> > custom relative path instead of default "--prefix" relative path?
>
> No, adding yet another option to resolve relative paths in
> configuration looks like a bad idea to me.  Resolving these from
> prefix looks perfectly correct and expected.

All right! Thanks for the feedback.

Fabiano Furtado

From 4slam at mythicflow.com  Fri Jul 14 19:33:23 2023
From: 4slam at mythicflow.com (aslamK)
Date: Fri, 14 Jul 2023 19:33:23 +0000
Subject: Ubuntu repo update warns about skipping i386 packages on amd64
 machine.
In-Reply-To: <7393b136-2505-99eb-6f33-5bb8ed174ee3@mythicflow.com>
References: <79f7d182-d75e-90b3-b26a-662000c21263@mythicflow.com>
 <272fed1d-302a-154b-d286-f5ffa8e484a1@nginx.com>
 <7393b136-2505-99eb-6f33-5bb8ed174ee3@mythicflow.com>
Message-ID: <e2cf3bdf-5600-20fa-0850-7f3ffa296799@mythicflow.com>

Thanks, Konstantin!

aslamK

>> In Ubuntu 22.04 (amd64), 'apt update' reports the following:
>>
>> N:
>>
>> Skipping acquire of configured file 'nginx/binary-i386/Packages'
>> as repository '
>> http://nginx.org/packages/u
>> buntu jammy InRelease'
>> doesn't support architecture 'i386'
>
> Looks like you have a foreign dpkg architecture enabled (i386) on an amd64 host. You may check it with `dpkg --print-foreign-architectures`.

That is indeed the case.

> If that's true, you can add arch=amd64 to sources.d/nginx.list options, so it will look similar to:
>
> deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu jammy nginx

Yep, that fixed it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230714/93c26927/attachment.htm>

From softwareinfojam at gmail.com  Thu Jul 20 00:42:45 2023
From: softwareinfojam at gmail.com (Software Info)
Date: Wed, 19 Jul 2023 19:42:45 -0500
Subject: Geoip2 module question
Message-ID: <CAFPCYA3-WByyCgxF5YTi44RcgnanmZod8jgvtvgAXX6OpwB=qg@mail.gmail.com>

Hi All,
I am running oracle Linux with free nginx and I have been trying to
get the nginx-geoip2-module.so module. It's not in any repo that I
have seen and I have had problems compiling it. I used to use this on
FreeBSD.  I am wondering why it's not more available in the Linux
repositories. Any thoughts?

From wangjiahao at openresty.com  Thu Jul 20 03:58:12 2023
From: wangjiahao at openresty.com (Jiahao Wang)
Date: Thu, 20 Jul 2023 11:58:12 +0800
Subject: [ANN] OpenResty 1.21.4.2 released
Message-ID: <CAOJ00aiaGt6D5-vGTxUrXNv01EMedOP_kcPvquOFVdEUZPepZQ@mail.gmail.com>

Hi folks,

I am happy to announce the new formal release, 1.21.4.2, of our OpenResty
web platform based on NGINX and LuaJIT. You can check the full release note
here:

http://openresty.org/en/ann-1021004002.html

You can download the software packages here:

http://openresty.org/en/download.html

The highlights of this release include:

- LuaJIT
    - Avoid negation of signed integers in C that may hold INT*_MIN, since
      recent C compilers 'take advantage' of the undefined behavior, this
      completely changes the meaning of expressions like (k == -k).
    - Correct fix for stack check when recording BC_VARG.
    - Fix trace join to BC_JLOOP originating from BC_ITERN.
    - Fix math.floor() and math.ceil().
    - Many fixes imported from Mike Pall's upstream
https://github.com/luajit/luajit repository.
- Fixed a bug that uses memory after free when encountering an invalid
IF-Match request header.
- Implements monotonic_msec() and monotonic_time() in resty.core.time.
- Includes Apple Silicon FFI ABI limitation workaround.
- Reimplemented tcpsock:sslhandshake, coroutine wrapper, and
ngx.req.is_internal with FFI.
- SSL/TLS supports passphrase protected private key.
- Fixes a segmentation fault when getting headers via ngx.req.raw_header
with
  malformed requests.
- Fixed potential null pointer dereference.
- lua-cjson module
    - empty_array can not work on Apple because cjson did not compare light
userdata
      address with masked address. Since we used json_lightudata_mask when
creating
      lightuserdata, same mask should be applied when comparing the return
of touserdata.
- headers-more-nginx-module module
    - Fixes crashes while accessing uninitialized pointers.
- lua-resty-websocket module
    - Adds mtls client cert support.
- lua-resty-memcached module
    - Implements init_pipeline(), commit_pipeline(), and cancel_pipeline().

For a comprehensive list of changes, please refer to the provided webpage.

Enjoy!

Best regards,
Jiahao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230720/567575a4/attachment.htm>

From r at roze.lv  Thu Jul 20 07:49:41 2023
From: r at roze.lv (Reinis Rozitis)
Date: Thu, 20 Jul 2023 10:49:41 +0300
Subject: Geoip2 module question
In-Reply-To: <CAFPCYA3-WByyCgxF5YTi44RcgnanmZod8jgvtvgAXX6OpwB=qg@mail.gmail.com>
References: <CAFPCYA3-WByyCgxF5YTi44RcgnanmZod8jgvtvgAXX6OpwB=qg@mail.gmail.com>
Message-ID: <000001d9bade$be575200$3b05f600$@roze.lv>

> I am wondering why it's not more available in the Linux repositories. Any thoughts?

It's a third party module. Why it is not available in your particular linux distribution you'll have to ask the distribution maintainers (Oracle) as for example it's available in Opensuse https://software.opensuse.org/package/nginx-module-geoip2

My guess would be that it requires libmaxminddb which might or might not be compatible with the distribution licensing politics.

rr

From venefax at gmail.com  Thu Jul 20 13:18:30 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 20 Jul 2023 09:18:30 -0400
Subject: [ANN] OpenResty 1.21.4.2 released
In-Reply-To: <CAOJ00aiaGt6D5-vGTxUrXNv01EMedOP_kcPvquOFVdEUZPepZQ@mail.gmail.com>
References: <CAOJ00aiaGt6D5-vGTxUrXNv01EMedOP_kcPvquOFVdEUZPepZQ@mail.gmail.com>
Message-ID: <CAC9cSODWy9qATue=ybY2G3AzGOup9HJBnVJt=Jw02YV62yNsQA@mail.gmail.com>

I get a timeout error when doing this
git clone git://
github.com/yaoweibin/ngx_http_substitutions_filter_module.git
but I need this module for my openresty installation
Does any body know how to fix this?

On Wed, Jul 19, 2023 at 11:58 PM Jiahao Wang via nginx <nginx at nginx.org>
wrote:

> Hi folks,
>
> I am happy to announce the new formal release, 1.21.4.2, of our OpenResty
> web platform based on NGINX and LuaJIT. You can check the full release
> note here:
>
> http://openresty.org/en/ann-1021004002.html
>
> You can download the software packages here:
>
> http://openresty.org/en/download.html
>
> The highlights of this release include:
>
> - LuaJIT
>     - Avoid negation of signed integers in C that may hold INT*_MIN, since
>       recent C compilers 'take advantage' of the undefined behavior, this
>       completely changes the meaning of expressions like (k == -k).
>     - Correct fix for stack check when recording BC_VARG.
>     - Fix trace join to BC_JLOOP originating from BC_ITERN.
>     - Fix math.floor() and math.ceil().
>     - Many fixes imported from Mike Pall's upstream
> https://github.com/luajit/luajit repository.
> - Fixed a bug that uses memory after free when encountering an invalid
> IF-Match request header.
> - Implements monotonic_msec() and monotonic_time() in resty.core.time.
> - Includes Apple Silicon FFI ABI limitation workaround.
> - Reimplemented tcpsock:sslhandshake, coroutine wrapper, and
> ngx.req.is_internal with FFI.
> - SSL/TLS supports passphrase protected private key.
> - Fixes a segmentation fault when getting headers via ngx.req.raw_header
> with
>   malformed requests.
> - Fixed potential null pointer dereference.
> - lua-cjson module
>     - empty_array can not work on Apple because cjson did not compare
> light userdata
>       address with masked address. Since we used json_lightudata_mask when
> creating
>       lightuserdata, same mask should be applied when comparing the return
> of touserdata.
> - headers-more-nginx-module module
>     - Fixes crashes while accessing uninitialized pointers.
> - lua-resty-websocket module
>     - Adds mtls client cert support.
> - lua-resty-memcached module
>     - Implements init_pipeline(), commit_pipeline(), and cancel_pipeline().
>
> For a comprehensive list of changes, please refer to the provided webpage.
>
> Enjoy!
>
> Best regards,
> Jiahao
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230720/15890ed3/attachment.htm>

From venefax at gmail.com  Thu Jul 20 14:53:15 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 20 Jul 2023 10:53:15 -0400
Subject: Missing module ngx_http_substitutions_filter_module
Message-ID: <CAC9cSODKt1gxjSrqj4AywQVS7ARdgpqv9NaM2fOi_jKPdFs-jg@mail.gmail.com>

I am trying to install this module and I get a timeout
git clone
git://github.com/yaoweibin/ngx_http_substitutions_filter_module.git
does anybody know how to install this module?
It's a vital part of my nginx installation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230720/c65c1e2f/attachment.htm>

From osa at freebsd.org.ru  Thu Jul 20 15:30:50 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Thu, 20 Jul 2023 18:30:50 +0300
Subject: Missing module ngx_http_substitutions_filter_module
In-Reply-To: <CAC9cSODKt1gxjSrqj4AywQVS7ARdgpqv9NaM2fOi_jKPdFs-jg@mail.gmail.com>
References: <CAC9cSODKt1gxjSrqj4AywQVS7ARdgpqv9NaM2fOi_jKPdFs-jg@mail.gmail.com>
Message-ID: <ZLlTKgoJSjwSXjhN@FreeBSD.org.ru>

Hi there,

On Thu, Jul 20, 2023 at 10:53:15AM -0400, Saint Michael wrote:
> I am trying to install this module and I get a timeout
> git clone
> git://github.com/yaoweibin/ngx_http_substitutions_filter_module.git
> does anybody know how to install this module?
> It's a vital part of my nginx installation.

You'd probably need to check local settings and raise a support
request on GH for the issue.
Also, that module is a third-party product, so you can raise an issue
for that project on GH as well.

Hope that helps.

-- 
Sergey A. Osokin

From sca at andreasschulze.de  Thu Jul 20 15:38:28 2023
From: sca at andreasschulze.de (A. Schulze)
Date: Thu, 20 Jul 2023 17:38:28 +0200
Subject: [ANN] OpenResty 1.21.4.2 released
In-Reply-To: <CAC9cSODWy9qATue=ybY2G3AzGOup9HJBnVJt=Jw02YV62yNsQA@mail.gmail.com>
References: <CAOJ00aiaGt6D5-vGTxUrXNv01EMedOP_kcPvquOFVdEUZPepZQ@mail.gmail.com>
 <CAC9cSODWy9qATue=ybY2G3AzGOup9HJBnVJt=Jw02YV62yNsQA@mail.gmail.com>
Message-ID: <a0e0cb51-a2a2-081d-f858-2203a329aed8@andreasschulze.de>



Am 20.07.23 um 15:18 schrieb Saint Michael:
> I get a timeout error when doing this
> git clone git://github.com/yaoweibin/ngx_http_substitutions_filter_module.git 

this isn't what I would use. I tried
- git clone https://github.com/yaoweibin/ngx_http_substitutions_filter_module.git
- git clone git at github.com:yaoweibin/ngx_http_substitutions_filter_module.git

and both work. Your version timeout here, too.

Andreas

From venefax at gmail.com  Thu Jul 20 15:56:21 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 20 Jul 2023 11:56:21 -0400
Subject: [ANN] OpenResty 1.21.4.2 released
In-Reply-To: <a0e0cb51-a2a2-081d-f858-2203a329aed8@andreasschulze.de>
References: <CAOJ00aiaGt6D5-vGTxUrXNv01EMedOP_kcPvquOFVdEUZPepZQ@mail.gmail.com>
 <CAC9cSODWy9qATue=ybY2G3AzGOup9HJBnVJt=Jw02YV62yNsQA@mail.gmail.com>
 <a0e0cb51-a2a2-081d-f858-2203a329aed8@andreasschulze.de>
Message-ID: <CAC9cSOAwKUc9U66z1NuiaPazYK1t1H8obj9jYGJwYkKGS=GbBw@mail.gmail.com>

It works fine with https://
Thanks to everybody.

On Thu, Jul 20, 2023 at 11:38 AM A. Schulze via nginx <nginx at nginx.org>
wrote:

>
>
> Am 20.07.23 um 15:18 schrieb Saint Michael:
> > I get a timeout error when doing this
> > git clone git://
> github.com/yaoweibin/ngx_http_substitutions_filter_module.git
>
> this isn't what I would use. I tried
> - git clone
> https://github.com/yaoweibin/ngx_http_substitutions_filter_module.git
> - git clone git at github.com:
> yaoweibin/ngx_http_substitutions_filter_module.git
>
> and both work. Your version timeout here, too.
>
> Andreas
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230720/e58b5dac/attachment-0001.htm>

From rarathore at ptc.com  Mon Jul 24 10:36:30 2023
From: rarathore at ptc.com (Rathore, Rajendra)
Date: Mon, 24 Jul 2023 10:36:30 +0000
Subject: restricting the http method for all location and enable the same for
 specific location
Message-ID: <BY3PR17MB539555B68AA82852F4127E06B602A@BY3PR17MB5395.namprd17.prod.outlook.com>

Hi Team,

We are looking for restricting the http method for all location  and enable the same for specific location, I found the way in Apache http server, I am unable to find the same in NGINX, can you please guide me here, how to achieve it.


Code snippet works in Apache Http server:
<LocationMatch "/ABCD/*">
                AllowMethods GET HEAD POST PUT DELETE /*disable the methods*/
           </LocationMatch>

/*enable same method using below code*/
<LocationMatch "/Windchill/oauth/servlet/odata/PTC/GetCSRFToken()">
             AllowMethods GET HEAD POST PUT DELETE OPTIONS
           </LocationMatch>




Thanks and Regards,
Rajendra Rathore
9922701491

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230724/60330c68/attachment.htm>

From anoopalias01 at gmail.com  Tue Jul 25 04:31:18 2023
From: anoopalias01 at gmail.com (Anoop Alias)
Date: Tue, 25 Jul 2023 10:01:18 +0530
Subject: quic listen on multiple vhost
Message-ID: <CAO6TEX3hRY+3dSj0pzN+sHbgm+or-eFgZN8ETFZt1A923LOgkQ@mail.gmail.com>

Hi,

I am trying to setup nginx with multiple vhost and quic support for all and
using sample config as per
https://www.nginx.com/blog/binary-packages-for-preview-nginx-quic-http3-implementation/

server {
listen    65.109.175.140:443 ssl ;
listen    65.109.175.140:443 quic reuseport;
server_name a.com;
.............
.............................
}
server {
listen    65.109.175.140:443 ssl ;
listen    65.109.175.140:443 quic reuseport;
server_name b.com;
.............
.............................
}

This however is throwing an error

# nginx -t
nginx: [emerg] duplicate listen options for 65.109.175.140:443 in
/etc/nginx/sites-enabled/b.com.conf:105
nginx: configuration file /etc/nginx/nginx.conf test failed

What am I doing wrong?


-- 
*Anoop P Alias*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230725/a69d4cf5/attachment.htm>

From r at roze.lv  Tue Jul 25 06:52:19 2023
From: r at roze.lv (Reinis Rozitis)
Date: Tue, 25 Jul 2023 09:52:19 +0300
Subject: quic listen on multiple vhost
In-Reply-To: <CAO6TEX3hRY+3dSj0pzN+sHbgm+or-eFgZN8ETFZt1A923LOgkQ@mail.gmail.com>
References: <CAO6TEX3hRY+3dSj0pzN+sHbgm+or-eFgZN8ETFZt1A923LOgkQ@mail.gmail.com>
Message-ID: <000001d9bec4$8fd2e1d0$af78a570$@roze.lv>

> # nginx -t
> nginx: [emerg] duplicate listen options for http://65.109.175.140:443 in /etc/nginx/sites-enabled/b.com.conf:105
> nginx: configuration file /etc/nginx/nginx.conf test failed
> 
> What am I doing wrong?

Probably complains about the duplicate 'reuseport' - leave it just only on one listen directive.

rr


From laurent.crosnier at accenture.com  Fri Jul 28 13:57:56 2023
From: laurent.crosnier at accenture.com (Crosnier, Laurent)
Date: Fri, 28 Jul 2023 13:57:56 +0000
Subject: Limit upload time
Message-ID: <DM6P114MB1334857F480F39A3D6615FF88F06A@DM6P114MB1334.NAMP114.PROD.OUTLOOK.COM>

Hello team,

I am trying to block uploads when they reach 10 seconds.
I tried many directives, just like this:

 +++++++++++++

    location / {
        proxy_set_header    X-Real-IP  $remote_addr;
        proxy_set_header    X-Forwarded-For $remote_addr;
        proxy_set_header    X-Forwarded-Proto HTTPS;
        proxy_set_header    Host $host;
        proxy_pass          https://10.0.1.48:443;
        keepalive_timeout            10;
        proxy_read_timeout           10s;
        proxy_connect_timeout        10s;
        proxy_send_timeout           10s;
        send_timeout                 10s;
        keepalive_time               10s;
        client_body_timeout          10s;
}

But none of these options seem to work, as in my logs, I'm still seeing my uploads exceeding 10 seconds:

++++++++++
********* - - [28/Jul/2023:15:22:03 +0200] "POST /api/knowledge-base/media/e9702102-f1ec-458c-8b49-6b3394bee29a HTTP/1.1" 201 775 "https://**********/knowledge-base/upload/?sortBy=name&sortDirection=asc&unit=19647654-acc7-493c-9b0f-d17f4542f339" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36" T="32.099" P="6967" XF="-"
++++++++++

I could not find any other directive to limit times for my upload request.
Is there another right way to do it ?

Thanks,

Laurent




________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security, AI-powered support capabilities, and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230728/4d752848/attachment.htm>

From mdounin at mdounin.ru  Sun Jul 30 19:29:02 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 30 Jul 2023 22:29:02 +0300
Subject: Limit upload time
In-Reply-To: <DM6P114MB1334857F480F39A3D6615FF88F06A@DM6P114MB1334.NAMP114.PROD.OUTLOOK.COM>
References: <DM6P114MB1334857F480F39A3D6615FF88F06A@DM6P114MB1334.NAMP114.PROD.OUTLOOK.COM>
Message-ID: <ZMa5/ogdjdDylIJD@mdounin.ru>

Hello!

On Fri, Jul 28, 2023 at 01:57:56PM +0000, Crosnier, Laurent via nginx wrote:

> Hello team,
> 
> I am trying to block uploads when they reach 10 seconds.
> I tried many directives, just like this:
> 
>  +++++++++++++
> 
>     location / {
>         proxy_set_header    X-Real-IP  $remote_addr;
>         proxy_set_header    X-Forwarded-For $remote_addr;
>         proxy_set_header    X-Forwarded-Proto HTTPS;
>         proxy_set_header    Host $host;
>         proxy_pass          https://10.0.1.48:443;
>         keepalive_timeout            10;
>         proxy_read_timeout           10s;
>         proxy_connect_timeout        10s;
>         proxy_send_timeout           10s;
>         send_timeout                 10s;
>         keepalive_time               10s;
>         client_body_timeout          10s;
> }
> 
> But none of these options seem to work, as in my logs, I'm still seeing my uploads exceeding 10 seconds:
> 
> ++++++++++
> ********* - - [28/Jul/2023:15:22:03 +0200] "POST /api/knowledge-base/media/e9702102-f1ec-458c-8b49-6b3394bee29a HTTP/1.1" 201 775 "https://**********/knowledge-base/upload/?sortBy=name&sortDirection=asc&unit=19647654-acc7-493c-9b0f-d17f4542f339" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36" T="32.099" P="6967" XF="-"
> ++++++++++
> 
> I could not find any other directive to limit times for my upload request.
> Is there another right way to do it ?

For client request body, the only available timeout option is 
client_body_timeout, which defines a timeout between two read 
operations, but not a total upload time (see 
http://nginx.org/r/client_body_timeout for details).  It can be 
accompanied by limit_conn (http://nginx.org/r/limit_conn) to limit 
the total number of connections from each client.

If you want something more sophisticated, an option to consider 
might be "proxy_request_buffering off;" and appropriate limits on 
the backend side (see https://nginx.org/r/proxy_request_buffering 
for details).  This might not be a good solution though, since in 
most cases keeping connections on nginx side is way cheaper than 
passing them to backends.

-- 
Maxim Dounin
http://mdounin.ru/