Re: [PATCH]HTTP/2 connection not properly closing during graceful shutdown

Hi, On Mon, May 06, 2024 at 11:14:24AM +0800, ka...@kasei.im wrote: > Hello, > > Thanks for your confirmation and explanations. > > The following is a modified patch. In my test it would send GOAWAY(on > stream id 0), same as the previous one, but call > ngx_http_v2_finalize_connection instead o

Re: [PATCH] Stream: allow servers with no handler

> On 27 Jun 2024, at 17:33, Roman Arutyunyan wrote: > > # HG changeset patch > # User Roman Arutyunyan > # Date 1719494996 -14400 > # Thu Jun 27 17:29:56 2024 +0400 > # Node ID 252582428b60f3422aa3b25dac8cca94edd43c34 > # Parent 4fbc38ad3c8a8ed798676b8aceda5ed70ef3 > Stream: allow ser

[nginx] Stream: allow servers with no handler.

details: https://hg.nginx.org/nginx/rev/072ca4906154 branches: changeset: 9269:072ca4906154 user: Roman Arutyunyan date: Thu Jun 27 17:29:56 2024 +0400 description: Stream: allow servers with no handler. Previously handlers were mandatory. However they are not always needed. For ex

Re: [PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

On 7/10/2024 6:16 AM, Roman Arutyunyan wrote: Hi, On Thu, Jun 13, 2024 at 03:29:03PM -0700, Aleksei Bavshin wrote: # HG changeset patch # User Aleksei Bavshin # Date 1712181327 25200 # Wed Apr 03 14:55:27 2024 -0700 # Node ID 375fa42f1a6010692a8782c4f03c6ad465d3f7f7 # Parent 8c8d8118c7ac

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

On 7/9/2024 9:22 AM, Roman Arutyunyan wrote: Hi, On Mon, Jul 08, 2024 at 06:20:58PM +0400, Roman Arutyunyan wrote: Hi, On Thu, Jun 13, 2024 at 03:28:56PM -0700, Aleksei Bavshin wrote: # HG changeset patch # User Ruslan Ermilov # Date 1392462754 -14400 # Sat Feb 15 15:12:34 2014 +0400 #

Re: [PATCH]HTTP/2 connection not properly closing during graceful shutdown

> On 11 Jul 2024, at 13:33, Roman Arutyunyan wrote: > > Hi, > > On Mon, May 06, 2024 at 11:14:24AM +0800, ka...@kasei.im wrote: >> Hello, >> >> Thanks for your confirmation and explanations. >> >> The following is a modified patch. In my test it would send GOAWAY(on >> stream id 0), same as t

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Do you happen to know if there remains any gap in obvious capability provided by a module like jdomain compared to this? Perhaps it would be worth checking to ensure nothing obvious is not implemented? The one that I see is the ability to control if a resolution is IPv4, IPv6 or mixed. Is this so

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

On 7/11/2024 12:15 PM, Mathew Heard wrote: Do you happen to know if there remains any gap in obvious capability provided by a module like jdomain compared to this? An obvious difference is that the jdomain directive performs resolution on demand instead of periodic polling, but that's a design

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

On Fri, 12 Jul 2024 at 05:42, Aleksei Bavshin wrote: > > On 7/11/2024 12:15 PM, Mathew Heard wrote: > > Do you happen to know if there remains any gap in obvious capability > > provided by a module like jdomain compared to this? > > An obvious difference is that the jdomain directive performs reso

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

On 7/11/2024 12:58 PM, Mathew Heard wrote: On Fri, 12 Jul 2024 at 05:42, Aleksei Bavshin wrote: On 7/11/2024 12:15 PM, Mathew Heard wrote: Do you happen to know if there remains any gap in obvious capability provided by a module like jdomain compared to this? An obvious difference is that t

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Thank you Aleksi, I think you are right. Thats the only one of our use cases using jdomain that I was concerned wouldn't be met by this feature. On Fri, 12 Jul 2024 at 06:32, Aleksei Bavshin wrote: > > On 7/11/2024 12:58 PM, Mathew Heard wrote: > > On Fri, 12 Jul 2024 at 05:42, Aleksei Bavshin w