From xeioex at nginx.com  Tue Apr  8 21:56:43 2025
From: xeioex at nginx.com (Dmitry Volyntsev)
Date: Tue, 8 Apr 2025 14:56:43 -0700
Subject: njs-0.8.10
Message-ID: <8d6f0793-da67-4453-905a-54154a4dff2c@nginx.com>

Hello,

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

This release introduced WebCrypto API, TextEncoder, TextDecoder, crypto,
querystring, xml modules for QuickJS engine.

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

Additional examples and howtos can be found here:

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

Changes with njs 0.8.10                                          08 Apr 2025

     nginx modules:

     *) Feature: reading r.requestText or r.requestBuffer from
        a temp file.
        Previously, an exception was thrown when accessing r.requestText
        or r.requestBuffer if a client request body size exceeded
        client_body_buffer_size.

     *) Improvement: improved reporting of unhandled promise rejections.

     *) Bugfix: fixed name corruption in variable and header processing.

     *) Bugfix: fixed SharedDict.incr() with empty init argument
        for QuickJS engine.

     *) Bugfix: accepting response headers with underscore characters
        in Fetch API.

     Core:

     *) Change: fixed serializeToString().
        Previously, serializeToString() was exclusiveC14n() which returned
        string instead of Buffer. According to the published 
documentation it
        should be c14n().

     *) Feature: added WebCrypto API for QuickJS engine.

     *) Feature: added TextEncoder/TextDecoder for QuickJS engine.

     *) Feature: added querystring module for QuickJS engine.

     *) Feature: added crypto module for QuickJS engine.

     *) Feature: added xml module for QuickJS engine.

     *) Feature: added support for QuickJS-NG library.

     *) Bugfix: fixed buffer.concat() with a single argument in quickjs.

     *) Bugfix: added missed syntax error for await in template literal.

     *) Bugfix: fixed non-NULL terminated strings formatting in
        exceptions for QuickJS engine.

     *) Bugfix: fixed compatibility with recent change in QuickJS
        and QuickJS-NG.

From bmvishwas at gmail.com  Mon Apr 14 06:06:48 2025
From: bmvishwas at gmail.com (Vishwas Bm)
Date: Mon, 14 Apr 2025 11:36:48 +0530
Subject: Stable release date ?
In-Reply-To: <729DAF79-2B69-442D-9020-49CD723FA297@nginx.com>
References: <CANgk=832nKHOUyyn2xjhdQvxWK8awisB9_S=kTyOS5Dh2fbU5w@mail.gmail.com>
 <729DAF79-2B69-442D-9020-49CD723FA297@nginx.com>
Message-ID: <CANgk=83QVjXXe=azrG7cT9RFvu2rYezheih1YP-3_D8rXB-jow@mail.gmail.com>

Is this planned for release this week ?

*Thanks & Regards,*
*Vishwas*

On Tue, Mar 18, 2025, 11:28 Roman Arutyunyan <arut at nginx.com> wrote:

> Hello,
>
> Typically it's around April 12 each year.
>
> On 17 Mar 2025, at 3:42 PM, Vishwas Bm <bmvishwas at gmail.com> wrote:
>
> Hi,
>
> When is the next nginx stable release date ?
>
> I do not see it mentioned here
> https://trac.nginx.org/nginx/roadmap
>
>
>
> Regards,
> Vishwas
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
>
> ----
> Roman Arutyunyan
> arut at nginx.com
>
>
>
>
> _______________________________________________
> 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/20250414/1622b664/attachment.htm>

From arut at nginx.com  Mon Apr 14 16:55:28 2025
From: arut at nginx.com (Roman Arutyunyan)
Date: Mon, 14 Apr 2025 20:55:28 +0400
Subject: Stable release date ?
In-Reply-To: <CANgk=83QVjXXe=azrG7cT9RFvu2rYezheih1YP-3_D8rXB-jow@mail.gmail.com>
References: <CANgk=832nKHOUyyn2xjhdQvxWK8awisB9_S=kTyOS5Dh2fbU5w@mail.gmail.com>
 <729DAF79-2B69-442D-9020-49CD723FA297@nginx.com>
 <CANgk=83QVjXXe=azrG7cT9RFvu2rYezheih1YP-3_D8rXB-jow@mail.gmail.com>
Message-ID: <956AA950-B58B-4A48-8EBF-0FABADAE0BB8@nginx.com>

Hi,

The next mainline release (1.27.5) is planned this week.
The next stable release (1.28.0) is planned next week.

> On 14 Apr 2025, at 10:06 AM, Vishwas Bm <bmvishwas at gmail.com> wrote:
> 
> Is this planned for release this week ?
> 
> Thanks & Regards,
> Vishwas
> 
> On Tue, Mar 18, 2025, 11:28 Roman Arutyunyan <arut at nginx.com <mailto:arut at nginx.com>> wrote:
>> Hello,
>> 
>> Typically it's around April 12 each year.
>> 
>>> On 17 Mar 2025, at 3:42 PM, Vishwas Bm <bmvishwas at gmail.com <mailto:bmvishwas at gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> When is the next nginx stable release date ?
>>> 
>>> I do not see it mentioned here
>>> https://trac.nginx.org/nginx/roadmap
>>> 
>>> 
>>> 
>>> Regards,
>>> Vishwas 
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>> https://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> ----
>> Roman Arutyunyan
>> arut at nginx.com <mailto:arut at nginx.com>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org <mailto:nginx at nginx.org>
>> https://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

----
Roman Arutyunyan
arut at nginx.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250414/692380c4/attachment.htm>

From pluknet at nginx.com  Wed Apr 16 14:14:17 2025
From: pluknet at nginx.com (Sergey Kandaurov)
Date: Wed, 16 Apr 2025 18:14:17 +0400
Subject: nginx-1.27.5
Message-ID: <6D04CE30-6BCC-4397-B084-E8C8D70C70EA@nginx.com>

Changes with nginx 1.27.5                                        16 Apr 2025

    *) Feature: CUBIC congestion control in QUIC connections.

    *) Change: the maximum size limit for SSL sessions cached in shared
       memory has been raised to 8192.

    *) Bugfix: in the "grpc_ssl_password_file", "proxy_ssl_password_file",
       and "uwsgi_ssl_password_file" directives when loading SSL
       certificates and encrypted keys from variables; the bug had appeared
       in 1.23.1.

    *) Bugfix: in the $ssl_curve and $ssl_curves variables when using
       pluggable curves in OpenSSL.

    *) Bugfix: nginx could not be built with musl libc.
       Thanks to Piotr Sikora.

    *) Performance improvements and bugfixes in HTTP/3.


-- 
Sergey Kandaurov

From srebecchi at kameleoon.com  Wed Apr 23 10:07:21 2025
From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=)
Date: Wed, 23 Apr 2025 12:07:21 +0200
Subject: use a secondary upstream as backup
Message-ID: <CA+ts6nrcGQTkmoNRnieKzL1g6n9rXX+-RAHBJ-BOYqOMg7nhrA@mail.gmail.com>

Hello,

I understand that within an upstream block, some servers can be marked as
backup, meaning NGINX will only use them if all primary servers fail.

In my case, I have some servers running over HTTP and would like to
configure HTTPS servers as backups. However, since an upstream can only use
one protocol, this setup isn't currently possible.

One solution I had in mind was to define a primary HTTP upstream and fall
back to a secondary HTTPS upstream if the first one fails, meaning all
servers in the primary upstream are unavailable. It could give something
like the example below. However, I couldn't find a way to implement this in
the NGINX documentation.

Is there a feature like this planned, or one that could be considered for
future development?

Thank you,
Sébastien

---

upstream main_upstream {
  server <ip here>:80
  server <ip here>:80
  <etc>
}

upstream secondary_upstream {
  server <ip here>:443
  server <ip here>:443
  <etc>
}

location / {
  proxy_pass http://main_upstream *backup https://secondary_upstream
<https://secondary_upstream>*;
  <etc>
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250423/f7a976c7/attachment.htm>

From osa at freebsd.org.ru  Wed Apr 23 13:26:06 2025
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Wed, 23 Apr 2025 16:26:06 +0300
Subject: use a secondary upstream as backup
In-Reply-To: <CA+ts6nrcGQTkmoNRnieKzL1g6n9rXX+-RAHBJ-BOYqOMg7nhrA@mail.gmail.com>
References: <CA+ts6nrcGQTkmoNRnieKzL1g6n9rXX+-RAHBJ-BOYqOMg7nhrA@mail.gmail.com>
Message-ID: <aAjqbixEYJZd93BU@FreeBSD.org.ru>

Hi Sébastien,
hope you're doing well.

Thanks for the question.

On Wed, Apr 23, 2025 at 12:07:21PM +0200, Sébastien Rebecchi via nginx wrote:
> backup, meaning NGINX will only use them if all primary servers fail.
> 
> In my case, I have some servers running over HTTP and would like to
> configure HTTPS servers as backups. However, since an upstream can only use
> one protocol, this setup isn't currently possible.

[...]

The solution you may help and you may want to try to implement is "double"
proxy, where:
- at first, nginx is proxy to the loopback upstream, i.e. to itself
- on the second step nginx proxies from loopback to an original upstream

So, the original upstream block will look like this:

upstream insecure {
    server A.B.C.D:80;    # http server
    server 127.0.0.1:8999;

    <other directives here>
}

upstream secure {
    server E.F.G.H:443;    # https

    <other directives here>
}

<other servers here>

server {
    listen 127.0.0.1:8999;

    location / {
        proxy_pass https://secure;

        <other directives here>
    }
}

> Is there a feature like this planned, or one that could be considered for
> future development?

I don't think such feature is planned at the moment, just because all
servers defined in the same upstream should be configured equally.

Hope that helps.
Thank you.

-- 
Sergey A. Osokin

From l.crilly at f5.com  Wed Apr 23 13:44:40 2025
From: l.crilly at f5.com (Liam Crilly)
Date: Wed, 23 Apr 2025 13:44:40 +0000
Subject: use a secondary upstream as backup
In-Reply-To: <aAjqbixEYJZd93BU@FreeBSD.org.ru>
References: <CA+ts6nrcGQTkmoNRnieKzL1g6n9rXX+-RAHBJ-BOYqOMg7nhrA@mail.gmail.com>
 <aAjqbixEYJZd93BU@FreeBSD.org.ru>
Message-ID: <DM8PR01MB6998A0B9F14EC778B89EC644A5BA2@DM8PR01MB6998.prod.exchangelabs.com>

Alternative approach would be to use error_page to catch the 5xx response (502 I think)
when there are no available upstream servers and then, from a named location, proxy_pass
with HTTPS to the same upstream group.

Modifying the original sample config below.
There is a blog post for similar use case here[1] but it is quite old ;)

Cheers,
Liam.

[1] https://blog.nginx.org/blog/capturing-5xx-errors-debug-server

---

upstream main_upstream {
  server <ip here>:80
  server <ip here>:80
  <etc>
}

upstream secondary_upstream {
  server <ip here>:443
  server <ip here>:443
  <etc>
}

location / {
  proxy_pass http://main_upstream;
  error_page 502 @try_secondary;
  <etc>
}

location @try_secondary {
  proxy_pass https://secondary_upstream;
  <etc>
}

________________________________________
From: nginx <nginx-bounces at nginx.org> on behalf of Sergey A. Osokin <osa at freebsd.org.ru>
Sent: 23 April 2025 14:26
To: Sébastien Rebecchi <srebecchi at kameleoon.com>
Cc: nginx mailing list <nginx at nginx.org>
Subject: Re: use a secondary upstream as backup

CAUTION: This email has been sent from an external source. Do not click links, open attachments, or provide sensitive business information unless you can verify the sender’s legitimacy.


Hi Sébastien,
hope you're doing well.

Thanks for the question.

On Wed, Apr 23, 2025 at 12:07:21PM +0200, Sébastien Rebecchi via nginx wrote:
> backup, meaning NGINX will only use them if all primary servers fail.
>
> In my case, I have some servers running over HTTP and would like to
> configure HTTPS servers as backups. However, since an upstream can only use
> one protocol, this setup isn't currently possible.

[...]

The solution you may help and you may want to try to implement is "double"
proxy, where:
- at first, nginx is proxy to the loopback upstream, i.e. to itself
- on the second step nginx proxies from loopback to an original upstream

So, the original upstream block will look like this:

upstream insecure {
    server A.B.C.D:80;    # http server
    server 127.0.0.1:8999;

    <other directives here>
}

upstream secure {
    server E.F.G.H:443;    # https

    <other directives here>
}

<other servers here>

server {
    listen 127.0.0.1:8999;

    location / {
        proxy_pass https://secure;

        <other directives here>
    }
}

> Is there a feature like this planned, or one that could be considered for
> future development?

I don't think such feature is planned at the moment, just because all
servers defined in the same upstream should be configured equally.

Hope that helps.
Thank you.

--
Sergey A. Osokin
_______________________________________________
nginx mailing list
nginx at nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx

From pluknet at nginx.com  Wed Apr 23 13:59:42 2025
From: pluknet at nginx.com (Sergey Kandaurov)
Date: Wed, 23 Apr 2025 17:59:42 +0400
Subject: nginx-1.28.0
Message-ID: <40D0FACB-C34F-4C69-B44B-74C1A4AC61AA@nginx.com>

Changes with nginx 1.28.0                                        23 Apr 2025

    *) 1.28.x stable branch.

    *) Bugfix: nginx could not be built by gcc 15 if ngx_http_v2_module or
       ngx_http_v3_module modules were used.

    *) Bugfix: nginx might not be built by gcc 14 or newer with -O3 -flto
       optimization if ngx_http_v3_module was used.


-- 
Sergey Kandaurov

From srebecchi at kameleoon.com  Wed Apr 23 14:04:39 2025
From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=)
Date: Wed, 23 Apr 2025 16:04:39 +0200
Subject: use a secondary upstream as backup
In-Reply-To: <DM8PR01MB6998A0B9F14EC778B89EC644A5BA2@DM8PR01MB6998.prod.exchangelabs.com>
References: <CA+ts6nrcGQTkmoNRnieKzL1g6n9rXX+-RAHBJ-BOYqOMg7nhrA@mail.gmail.com>
 <aAjqbixEYJZd93BU@FreeBSD.org.ru>
 <DM8PR01MB6998A0B9F14EC778B89EC644A5BA2@DM8PR01MB6998.prod.exchangelabs.com>
Message-ID: <CA+ts6nr0KAORWbzYw97mL4JB8GbLj1di60NFLby+1vfEp8Z70g@mail.gmail.com>

Hi Sergey, Liam!

Thank you for your answers, they are really helpful!
I did not think of such kinds of solutions, they should both work fine for
my use case.

Have a great day

Sébastien

Le mer. 23 avr. 2025 à 15:44, Liam Crilly via nginx <nginx at nginx.org> a
écrit :

> Alternative approach would be to use error_page to catch the 5xx response
> (502 I think)
> when there are no available upstream servers and then, from a named
> location, proxy_pass
> with HTTPS to the same upstream group.
>
> Modifying the original sample config below.
> There is a blog post for similar use case here[1] but it is quite old ;)
>
> Cheers,
> Liam.
>
> [1] https://blog.nginx.org/blog/capturing-5xx-errors-debug-server
>
> ---
>
> upstream main_upstream {
>   server <ip here>:80
>   server <ip here>:80
>   <etc>
> }
>
> upstream secondary_upstream {
>   server <ip here>:443
>   server <ip here>:443
>   <etc>
> }
>
> location / {
>   proxy_pass http://main_upstream;
>   error_page 502 @try_secondary;
>   <etc>
> }
>
> location @try_secondary {
>   proxy_pass https://secondary_upstream;
>   <etc>
> }
>
> ________________________________________
> From: nginx <nginx-bounces at nginx.org> on behalf of Sergey A. Osokin <
> osa at freebsd.org.ru>
> Sent: 23 April 2025 14:26
> To: Sébastien Rebecchi <srebecchi at kameleoon.com>
> Cc: nginx mailing list <nginx at nginx.org>
> Subject: Re: use a secondary upstream as backup
>
> CAUTION: This email has been sent from an external source. Do not click
> links, open attachments, or provide sensitive business information unless
> you can verify the sender’s legitimacy.
>
>
> Hi Sébastien,
> hope you're doing well.
>
> Thanks for the question.
>
> On Wed, Apr 23, 2025 at 12:07:21PM +0200, Sébastien Rebecchi via nginx
> wrote:
> > backup, meaning NGINX will only use them if all primary servers fail.
> >
> > In my case, I have some servers running over HTTP and would like to
> > configure HTTPS servers as backups. However, since an upstream can only
> use
> > one protocol, this setup isn't currently possible.
>
> [...]
>
> The solution you may help and you may want to try to implement is "double"
> proxy, where:
> - at first, nginx is proxy to the loopback upstream, i.e. to itself
> - on the second step nginx proxies from loopback to an original upstream
>
> So, the original upstream block will look like this:
>
> upstream insecure {
>     server A.B.C.D:80;    # http server
>     server 127.0.0.1:8999;
>
>     <other directives here>
> }
>
> upstream secure {
>     server E.F.G.H:443;    # https
>
>     <other directives here>
> }
>
> <other servers here>
>
> server {
>     listen 127.0.0.1:8999;
>
>     location / {
>         proxy_pass https://secure;
>
>         <other directives here>
>     }
> }
>
> > Is there a feature like this planned, or one that could be considered for
> > future development?
>
> I don't think such feature is planned at the moment, just because all
> servers defined in the same upstream should be configured equally.
>
> Hope that helps.
> Thank you.
>
> --
> Sergey A. Osokin
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> 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/20250423/c71c8afd/attachment-0001.htm>