Re: Restarting service takes too much time

2022-11-30 Thread blason
Hi,

Did you check error log or syslog? Is that spitting out any errors? Do you
have SSL_OCSP settings configured and it might not be able to reach to the
protocol? 

I mean I had 45 portals and was facing a same issue. Later when I done the
debug I found that ocsp.godaddy.com was not reachable and it verifies every
time we reload the service.

Just a heads up though.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,295945,295946#msg-295946

___
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org


Restarting service takes too much time

2022-11-30 Thread Gus Flowers Starkiller
Hi, please could anyone tell me why the nginx service takes too much time
to restart? As we know, after some change with nginx the service must be
restarted, I do this with "nginx -s reload" or "systemctl restart nginx",
and this takes some three minutes or more. This process is happening in
servers with many websites (eg 200 sites). So, with a new nginx this
restart of nginx is immediate but with many sites this restart process of
nginx is very slow, I am using Debian with nginx and OWASP.

Thanks for your help.

-- 
*Gus Flowers*
___
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org


Re: [PATCH 0 of 2] unbuffered proxying CPU hog (ticket #2418)

2022-11-30 Thread Maxim Dounin
Hello!

On Wed, Nov 30, 2022 at 07:29:35PM +0400, Sergey Kandaurov wrote:

> > On 29 Nov 2022, at 02:12, Maxim Dounin  wrote:
> > 
> > Hello!
> > 
> > The following patch fixes CPU hog observed with unbuffered SSL proxying 
> > after SSL errors (ticket #2418).  Fix is to always clear c->read->ready
> > flag when returning errors from ngx_ssl_recv().
> > 
> > An additional patch cleans up some win32-specific edge cases (not expected
> > to appear in practice though) when c->read->ready is not cleared when
> > errors or EOFs are returned from ngx_wsarecv() and ngx_wsarecv_chain().
> > 
> 
> Hello!
> 
> Both patches look good to me.

Pushed to http://mdounin.ru/hg/nginx, thanks.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: [PATCH v2] Removed the casts within ngx_memcmp()

2022-11-30 Thread Maxim Dounin
Hello!

On Wed, Nov 30, 2022 at 11:49:18AM +0100, Alex Colomar wrote:

> On 11/30/22 05:22, Maxim Dounin wrote:
> > Hello!
> > 
> > Ping.
> 
> Sorry, I didn't know you were waiting for my confirmation.

Not exactly yours.  As per the project policy, patches need to be 
approved by other core developers before being committed.

Other reviews are appreciated though, especially from the authors 
of original submissions.

> >> # HG changeset patch
> >> # User Maxim Dounin 
> >> # Date 1668004692 -10800
> >> #  Wed Nov 09 17:38:12 2022 +0300
> >> # Node ID fc79ea0724a92c1f463625a11ed4cb785cd342b7
> >> # Parent  42bc158a47ecb3c2bd0396c723c307c757f2770e
> >> Fixed alignment of ngx_memmove()/ngx_movemem() macro definitions.
> 
> Makes sense.
> 
> >>
> >> diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
> >> --- a/src/core/ngx_string.h
> >> +++ b/src/core/ngx_string.h
> >> @@ -140,8 +140,8 @@ ngx_copy(u_char *dst, u_char *src, size_
> >>   #endif
> >>   
> >>   
> >> -#define ngx_memmove(dst, src, n)   (void) memmove(dst, src, n)
> >> -#define ngx_movemem(dst, src, n)   (((u_char *) memmove(dst, src, n)) + 
> >> (n))
> >> +#define ngx_memmove(dst, src, n)  (void) memmove(dst, src, n)
> >> +#define ngx_movemem(dst, src, n)  (((u_char *) memmove(dst, src, n)) + 
> >> (n))
> >>   
> >>   
> >>   /* msvc and icc7 compile memcmp() to the inline loop */
> >> # HG changeset patch
> >> # User Maxim Dounin 
> >> # Date 1668005196 -10800
> >> #  Wed Nov 09 17:46:36 2022 +0300
> >> # Node ID 5269880f00df1e5ae08299165ec43435b759c5a3
> >> # Parent  fc79ea0724a92c1f463625a11ed4cb785cd342b7
> >> Removed casts from ngx_memcmp() macro.
> >>
> >> Casts are believed to be not needed, since memcmp() has "const void *"
> >> arguments since introduction of the "void" type in C89.  And on pre-C89
> >> platforms nginx is unlikely to compile without warnings anyway, as there
> >> are no casts in memcpy() and memmove() calls.
> >>
> >> These casts were added in 1648:89a47f19b9ec without any details on why they
> >> were added, and Igor does not remember details either.  The most plausible
> >> explanation is that they were copied from ngx_strcmp() and were not really
> >> needed even at that time.
> >>
> >> Prodded by Alejandro Colomar.
> 
> And of course, this patch LGTM :)

Thanks, committed and will be available in the next release.  
Thanks for prodding this.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: [PATCH v2] Removed the casts within ngx_memcmp()

2022-11-30 Thread Maxim Dounin
Hello!

On Wed, Nov 30, 2022 at 04:17:15PM +0400, Sergey Kandaurov wrote:

> On Wed, Nov 09, 2022 at 06:03:24PM +0300, Maxim Dounin wrote:
> > # HG changeset patch
> > # User Maxim Dounin 
> > # Date 1668004692 -10800
> > #  Wed Nov 09 17:38:12 2022 +0300
> > # Node ID fc79ea0724a92c1f463625a11ed4cb785cd342b7
> > # Parent  42bc158a47ecb3c2bd0396c723c307c757f2770e
> > Fixed alignment of ngx_memmove()/ngx_movemem() macro definitions.
> > 
> > diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
> > --- a/src/core/ngx_string.h
> > +++ b/src/core/ngx_string.h
> > @@ -140,8 +140,8 @@ ngx_copy(u_char *dst, u_char *src, size_
> >  #endif
> >  
> >  
> > -#define ngx_memmove(dst, src, n)   (void) memmove(dst, src, n)
> > -#define ngx_movemem(dst, src, n)   (((u_char *) memmove(dst, src, n)) + 
> > (n))
> > +#define ngx_memmove(dst, src, n)  (void) memmove(dst, src, n)
> > +#define ngx_movemem(dst, src, n)  (((u_char *) memmove(dst, src, n)) + (n))
> >  
> >  
> >  /* msvc and icc7 compile memcmp() to the inline loop */
> > # HG changeset patch
> > # User Maxim Dounin 
> > # Date 1668005196 -10800
> > #  Wed Nov 09 17:46:36 2022 +0300
> > # Node ID 5269880f00df1e5ae08299165ec43435b759c5a3
> > # Parent  fc79ea0724a92c1f463625a11ed4cb785cd342b7
> > Removed casts from ngx_memcmp() macro.
> > 
> > Casts are believed to be not needed, since memcmp() has "const void *"
> > arguments since introduction of the "void" type in C89.  And on pre-C89
> > platforms nginx is unlikely to compile without warnings anyway, as there
> > are no casts in memcpy() and memmove() calls.
> > 
> > These casts were added in 1648:89a47f19b9ec without any details on why they
> > were added, and Igor does not remember details either.  The most plausible
> > explanation is that they were copied from ngx_strcmp() and were not really
> > needed even at that time.
> > 
> > Prodded by Alejandro Colomar.
> > 
> > diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
> > --- a/src/core/ngx_string.h
> > +++ b/src/core/ngx_string.h
> > @@ -145,7 +145,7 @@ ngx_copy(u_char *dst, u_char *src, size_
> >  
> >  
> >  /* msvc and icc7 compile memcmp() to the inline loop */
> > -#define ngx_memcmp(s1, s2, n)  memcmp((const char *) s1, (const char *) 
> > s2, n)
> > +#define ngx_memcmp(s1, s2, n) memcmp(s1, s2, n)
> >  
> >  
> >  u_char *ngx_cpystrn(u_char *dst, u_char *src, size_t n);
> > 
> 
> Looks good.

Pushed to http://mdounin.ru/hg/nginx, thanks.

> Indeed, old memcmp definition is traced back to pre-ANSI.
> In particular, you can find old implementation in 4.3BSD-Tahoe
> (named as "Routines described in memory(BA_LIB); System V compatibility")
> that uses "char *" arguments, until they were rewritten in 4.3BSD-Reno
> in ANSI C by Chris Torek.

>From unix-history-repo it looks like there was no memcmp() in 
string.h in 4.3BSD-Tahoe release, and memcmp() was instead 
available via memory.h, without any prototypes:

https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3_Tahoe/usr/src/include/string.h
https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3_Tahoe/usr/src/include/memory.h

And in 4.3BSD-Reno release it was already using "const void *".

https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3_Reno/usr/src/include/string.h

Looks like the variant with "const char *" prototypes available 
via string.h was only present shortly between these two versions.

This seems to match CSRG archive CDs from Kirk McKusick.

> Also, it seems that VC 6.0 has memcmp with non-const void argument
> as pre-C++98 (but I cannot support this clame with real facts).

It does not look like MSVC 6.0 can be downloaded from Microsoft 
now, though CD copies are available at least at:

https://winworldpc.com/product/visual-c/6x
https://archive.org/details/microsoft-visual-c-6.0-standard-edition

And memcmp() there is defined as follows:

$ grep memcmp string.h
_CRTIMP int __cdecl memcmp(const void *, const void *, size_t);
int __cdecl memcmp(const void *, const void *, size_t);

Though I'm pretty sure we don't care about anything older than 
MSVC2005 (which is still can be downloaded from Microsoft, BTW).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


RE: [PATCH] HTTP: add internal_redirect directive.

2022-11-30 Thread Aleksei Bavshin via nginx-devel
Hello,

> > The directive in question provides direct access to the
> > ngx_http_internal_redirect/ngx_http_named_location APIs,
> > allowing to simplify and optimize several real-life
> > configurations where the modules should be executed multiple
> > times/in a different order/with a different configuration/etc,
> > sometimes based on a condition evaluated during the request
> > processing.
> 
> No, thanks.
> 
> Discussions about adding the "goto" directive date back to at
> least 2009.  Igor's and my position on this are summarized here:
> 
> https://mailman.nginx.org/pipermail/nginx-ru/2017-April/059736.html
> 
> Hope this helps.

Thank you, I missed these threads while looking through the archives. I'm still 
getting used to the vast amount of knowledge that is available only in Russian, 
and sometimes forget to retry the search with a translated query.

So, Igor's main point was that a directive like that allows creating 
unmaintainable configurations and will be heavily abused? It is a fair point 
and it made me hesitate before submitting the patch. But there are already 
roundabout ways of achieving the same and providing an official and 
well-documented one may be beneficial.

I also wanted to point out that, unlike the previous requests, we're not 
looking for a way to reduce duplication in the configuration.  There are 
genuine cases, where applying several location configs one by one is the most 
optimal way to get a desired behavior. E.g., step-up authentication or reuse of 
the result of another access module -- the existing methods of implementing 
such configurations are complex and may negatively affect max RPS/request 
processing time.

---
It doesn't have to be a redirect either; that was just the most direct 
approach. The `error_page ...; return` idiom could work for these scenarios, if 
we could have a conditional return-like directive processed at POST_ACCESS or 
PRECONTENT. Although it would be less obvious and with its own share of 
pitfalls.

location /protected {
...

includeregular_error_pages.inc;

error_page 418 = @extra_auth;
recursive_error_pages  on;
post_auth_require  $not_suspicious  $var_from_subrequest ... 
error=418; # semantics similar to auth_jwt_require
}

If I failed to convince you on the topic of redirect, would you be open to a 
patch with that kind of directive?
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: nginx returns html instead of json response

2022-11-30 Thread Kaushal Shriyan
On Tue, Nov 29, 2022 at 9:58 PM Kaushal Shriyan 
wrote:

> Hi Francis,
>
> Thanks a lot for all your help and support. It worked. I have configured
> the below settings in nginx after a few attempts by tweaking it. It worked
> like a charm.
>
> location /apis {
> # First attempt to serve request as file, then
> # as directory, then fall back to displaying a 404.
> fastcgi_intercept_errors off;
> add_header "X-Debug-JSON-APIS" $http_accept always;
> fastcgi_pass 127.0.0.1:9000;
> include fastcgi.conf;
> fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>  }
>
> I have a follow up question related to the below error which appears in
> html instead of JSON format when I hit rest api calls
> http://mydomain.com/apis in case of when the MySQL Database service is
> down as part of testing the end to end flow. The flow is as follows:
>
> User -> Nginx webserver -> PHP-FPM upstream server -> MySQL Database.
>
> *The Website Encountered an Unexpected Error. Please try again Later *
>
>
> Is there a way to display the above string in JSON format?
>
> Please guide me. Thanks in advance.
>
> Best Regards,
>
> Kaushal
>


Hi,

Checking in again if someone can help me with my earlier post to this
mailing list? Please guide me. Thanks in advance.

Best Regards,

Kaushal
___
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org


Re: Content Security Policy Headers are not appearing

2022-11-30 Thread blason
I see - that;s a nice suggestion. Let me see how this goes.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,295928,295939#msg-295939

___
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org


Re: [PATCH 0 of 2] unbuffered proxying CPU hog (ticket #2418)

2022-11-30 Thread Sergey Kandaurov


> On 29 Nov 2022, at 02:12, Maxim Dounin  wrote:
> 
> Hello!
> 
> The following patch fixes CPU hog observed with unbuffered SSL proxying 
> after SSL errors (ticket #2418).  Fix is to always clear c->read->ready
> flag when returning errors from ngx_ssl_recv().
> 
> An additional patch cleans up some win32-specific edge cases (not expected
> to appear in practice though) when c->read->ready is not cleared when
> errors or EOFs are returned from ngx_wsarecv() and ngx_wsarecv_chain().
> 

Hello!

Both patches look good to me.

-- 
Sergey Kandaurov

___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: QUIC: position of RTT and congestion

2022-11-30 Thread Vladimir Homutov via nginx-devel
On Wed, Nov 30, 2022 at 08:10:29PM +0800, Yu Zhu wrote:
>
> Hi,
>
> As described in "rfc 9002 6. Loss Detection",  "RTT and congestion
> control are properties of the path", so moves first_rtt,
> latest_rtt, avg_rtt, min_rtt, rttvar and congestion from
> ngx_quic_connection_t to struct ngx_quic_path_t looks more
> reasonable?

yes, you are right.

Currently per-path calculations are not implemented, as well as path mtu
discovery and some other things.

___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: [PATCH v2] Removed the casts within ngx_memcmp()

2022-11-30 Thread Sergey Kandaurov
On Wed, Nov 09, 2022 at 06:03:24PM +0300, Maxim Dounin wrote:
> # HG changeset patch
> # User Maxim Dounin 
> # Date 1668004692 -10800
> #  Wed Nov 09 17:38:12 2022 +0300
> # Node ID fc79ea0724a92c1f463625a11ed4cb785cd342b7
> # Parent  42bc158a47ecb3c2bd0396c723c307c757f2770e
> Fixed alignment of ngx_memmove()/ngx_movemem() macro definitions.
> 
> diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
> --- a/src/core/ngx_string.h
> +++ b/src/core/ngx_string.h
> @@ -140,8 +140,8 @@ ngx_copy(u_char *dst, u_char *src, size_
>  #endif
>  
>  
> -#define ngx_memmove(dst, src, n)   (void) memmove(dst, src, n)
> -#define ngx_movemem(dst, src, n)   (((u_char *) memmove(dst, src, n)) + (n))
> +#define ngx_memmove(dst, src, n)  (void) memmove(dst, src, n)
> +#define ngx_movemem(dst, src, n)  (((u_char *) memmove(dst, src, n)) + (n))
>  
>  
>  /* msvc and icc7 compile memcmp() to the inline loop */
> # HG changeset patch
> # User Maxim Dounin 
> # Date 1668005196 -10800
> #  Wed Nov 09 17:46:36 2022 +0300
> # Node ID 5269880f00df1e5ae08299165ec43435b759c5a3
> # Parent  fc79ea0724a92c1f463625a11ed4cb785cd342b7
> Removed casts from ngx_memcmp() macro.
> 
> Casts are believed to be not needed, since memcmp() has "const void *"
> arguments since introduction of the "void" type in C89.  And on pre-C89
> platforms nginx is unlikely to compile without warnings anyway, as there
> are no casts in memcpy() and memmove() calls.
> 
> These casts were added in 1648:89a47f19b9ec without any details on why they
> were added, and Igor does not remember details either.  The most plausible
> explanation is that they were copied from ngx_strcmp() and were not really
> needed even at that time.
> 
> Prodded by Alejandro Colomar.
> 
> diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
> --- a/src/core/ngx_string.h
> +++ b/src/core/ngx_string.h
> @@ -145,7 +145,7 @@ ngx_copy(u_char *dst, u_char *src, size_
>  
>  
>  /* msvc and icc7 compile memcmp() to the inline loop */
> -#define ngx_memcmp(s1, s2, n)  memcmp((const char *) s1, (const char *) s2, 
> n)
> +#define ngx_memcmp(s1, s2, n) memcmp(s1, s2, n)
>  
>  
>  u_char *ngx_cpystrn(u_char *dst, u_char *src, size_t n);
> 

Looks good.

Indeed, old memcmp definition is traced back to pre-ANSI.
In particular, you can find old implementation in 4.3BSD-Tahoe
(named as "Routines described in memory(BA_LIB); System V compatibility")
that uses "char *" arguments, until they were rewritten in 4.3BSD-Reno
in ANSI C by Chris Torek.
Also, it seems that VC 6.0 has memcmp with non-const void argument
as pre-C++98 (but I cannot support this clame with real facts).
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


QUIC: position of RTT and congestion

2022-11-30 Thread Yu Zhu

Hi,

As described in "rfc 9002 6. Loss Detection",  "RTT and congestion control 
are properties of the path", so moves first_rtt, latest_rtt, avg_rtt, min_rtt, 
rttvar and congestion from ngx_quic_connection_t to struct ngx_quic_path_t 
looks more reasonable?





--
Yu Zhu___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: [PATCH v2] Removed the casts within ngx_memcmp()

2022-11-30 Thread Alex Colomar

Hello Maxim!

On 11/30/22 05:22, Maxim Dounin wrote:

Hello!

Ping.


Sorry, I didn't know you were waiting for my confirmation.



On Wed, Nov 09, 2022 at 06:03:24PM +0300, Maxim Dounin wrote:

[...]


# HG changeset patch
# User Maxim Dounin 
# Date 1668004692 -10800
#  Wed Nov 09 17:38:12 2022 +0300
# Node ID fc79ea0724a92c1f463625a11ed4cb785cd342b7
# Parent  42bc158a47ecb3c2bd0396c723c307c757f2770e
Fixed alignment of ngx_memmove()/ngx_movemem() macro definitions.


Makes sense.



diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
--- a/src/core/ngx_string.h
+++ b/src/core/ngx_string.h
@@ -140,8 +140,8 @@ ngx_copy(u_char *dst, u_char *src, size_
  #endif
  
  
-#define ngx_memmove(dst, src, n)   (void) memmove(dst, src, n)

-#define ngx_movemem(dst, src, n)   (((u_char *) memmove(dst, src, n)) + (n))
+#define ngx_memmove(dst, src, n)  (void) memmove(dst, src, n)
+#define ngx_movemem(dst, src, n)  (((u_char *) memmove(dst, src, n)) + (n))
  
  
  /* msvc and icc7 compile memcmp() to the inline loop */

# HG changeset patch
# User Maxim Dounin 
# Date 1668005196 -10800
#  Wed Nov 09 17:46:36 2022 +0300
# Node ID 5269880f00df1e5ae08299165ec43435b759c5a3
# Parent  fc79ea0724a92c1f463625a11ed4cb785cd342b7
Removed casts from ngx_memcmp() macro.

Casts are believed to be not needed, since memcmp() has "const void *"
arguments since introduction of the "void" type in C89.  And on pre-C89
platforms nginx is unlikely to compile without warnings anyway, as there
are no casts in memcpy() and memmove() calls.

These casts were added in 1648:89a47f19b9ec without any details on why they
were added, and Igor does not remember details either.  The most plausible
explanation is that they were copied from ngx_strcmp() and were not really
needed even at that time.

Prodded by Alejandro Colomar.


And of course, this patch LGTM :)

Cheers,

Alex



diff --git a/src/core/ngx_string.h b/src/core/ngx_string.h
--- a/src/core/ngx_string.h
+++ b/src/core/ngx_string.h
@@ -145,7 +145,7 @@ ngx_copy(u_char *dst, u_char *src, size_
  
  
  /* msvc and icc7 compile memcmp() to the inline loop */

-#define ngx_memcmp(s1, s2, n)  memcmp((const char *) s1, (const char *) s2, n)
+#define ngx_memcmp(s1, s2, n) memcmp(s1, s2, n)
  
  
  u_char *ngx_cpystrn(u_char *dst, u_char *src, size_t n);




--




OpenPGP_signature
Description: OpenPGP digital signature
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org


Re: [PATCH 08 of 10] QUIC: idle mode for main connection

2022-11-30 Thread Roman Arutyunyan
Hi,

On Tue, Nov 29, 2022 at 06:00:40PM +0400, Roman Arutyunyan wrote:
> Hi,
> 
> On Mon, Nov 28, 2022 at 09:40:05PM +0400, Sergey Kandaurov wrote:
> > On Thu, Nov 24, 2022 at 07:15:31PM +0400, Roman Arutyunyan wrote:
> > > Hi,
> > > 
> > > On Thu, Oct 20, 2022 at 06:25:03PM +0400, Roman Arutyunyan wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Oct 20, 2022 at 03:50:15PM +0400, Sergey Kandaurov wrote:
> > > > > On Thu, Sep 08, 2022 at 01:06:35PM +0400, Roman Arutyunyan wrote:
> > > > > > # HG changeset patch
> > > > > > # User Roman Arutyunyan 
> > > > > > # Date 1662627133 -14400
> > > > > > #  Thu Sep 08 12:52:13 2022 +0400
> > > > > > # Branch quic
> > > > > > # Node ID e0634a484d9a2d82d43f565d64a0a22e989ac1cb
> > > > > > # Parent  1dd6fabfdcb5b52af495f9d8fc00f64ae36a537c
> > > > > > QUIC: idle mode for main connection.
> > > > > > 
> > > > > > Now main QUIC connection for HTTP/3 always has c->idle flag set.  
> > > > > > This allows
> > > > > > the connection to receive worker shutdown notification.  It is 
> > > > > > passed to
> > > > > > application level via a new conf->shutdown() callback.
> > > > > > 
> > > > > > The HTTP/3 shutdown callback sends GOAWAY to client and gracefully 
> > > > > > shuts down
> > > > > > the QUIC connection.
> > > > > > 
> > > > > > diff --git a/src/event/quic/ngx_event_quic.c 
> > > > > > b/src/event/quic/ngx_event_quic.c
> > > > > > --- a/src/event/quic/ngx_event_quic.c
> > > > > > +++ b/src/event/quic/ngx_event_quic.c
> > > > > > @@ -341,6 +341,7 @@ ngx_quic_new_connection(ngx_connection_t
> > > > > >  return NULL;
> > > > > >  }
> > > > > >  
> > > > > > +c->idle = 1;
> > > > > >  ngx_reusable_connection(c, 1);
> > > > > >  
> > > > > >  ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0,
> > > > > > @@ -420,9 +421,9 @@ ngx_quic_input_handler(ngx_event_t *rev)
> > > > > >  }
> > > > > >  
> > > > > >  if (c->close) {
> > > > > > -qc->error = NGX_QUIC_ERR_NO_ERROR;
> > > > > > -qc->error_reason = "graceful shutdown";
> > > > > > -ngx_quic_close_connection(c, NGX_ERROR);
> > > > > > +if (qc->conf->shutdown) {
> > > > > 
> > > > > As previously discussed in private, this will need an additional check
> > > > > that we are not yet in qc->closing.
> > > > > 
> > > > > > +qc->conf->shutdown(c);
> > > > > > +}
> > > > > >  return;
> > > > > >  }
> > > > 
> > > > 
> > > > Yes, added the check.  Also, c->close is reset here similarly to HTTP/2
> > > > since we want to be able to handle future packets normally.
> > > > 
> > > > Also, current code which closes the connection instantly should remain 
> > > > for
> > > > connection reuse.  To tell reuse from shutdown we can check ngx_exiting.
> > > > Assuming reuse does not make sense in shutdown mode, this will work 
> > > > good.
> > > > 
> > > > > > diff --git a/src/event/quic/ngx_event_quic.h 
> > > > > > b/src/event/quic/ngx_event_quic.h
> > > > > > --- a/src/event/quic/ngx_event_quic.h
> > > > > > +++ b/src/event/quic/ngx_event_quic.h
> > > > > > @@ -28,6 +28,9 @@
> > > > > >  #define NGX_QUIC_STREAM_UNIDIRECTIONAL   0x02
> > > > > >  
> > > > > >  
> > > > > > +typedef void (*ngx_quic_shutdown_pt)(ngx_connection_t *c);
> > > > > > +
> > > > > > +
> > > > > >  typedef enum {
> > > > > >  NGX_QUIC_STREAM_SEND_READY = 0,
> > > > > >  NGX_QUIC_STREAM_SEND_SEND,
> > > > > > @@ -74,6 +77,8 @@ typedef struct {
> > > > > >  ngx_int_t  stream_reject_code_uni;
> > > > > >  ngx_int_t  stream_reject_code_bidi;
> > > > > >  
> > > > > > +ngx_quic_shutdown_pt   shutdown;
> > > > > > +
> > > > > >  u_char 
> > > > > > av_token_key[NGX_QUIC_AV_KEY_LEN];
> > > > > >  u_char 
> > > > > > sr_token_key[NGX_QUIC_SR_KEY_LEN];
> > > > > >  } ngx_quic_conf_t;
> > > > > > diff --git a/src/http/v3/ngx_http_v3.h b/src/http/v3/ngx_http_v3.h
> > > > > > --- a/src/http/v3/ngx_http_v3.h
> > > > > > +++ b/src/http/v3/ngx_http_v3.h
> > > > > > @@ -141,6 +141,7 @@ struct ngx_http_v3_session_s {
> > > > > >  uint64_t  next_push_id;
> > > > > >  uint64_t  max_push_id;
> > > > > >  uint64_t  goaway_push_id;
> > > > > > +uint64_t  next_request_id;
> > > > > >  
> > > > > >  off_t total_bytes;
> > > > > >  off_t payload_bytes;
> > > > > > @@ -158,6 +159,7 @@ void ngx_http_v3_init(ngx_connection_t *
> > > > > >  void ngx_http_v3_reset_connection(ngx_connection_t *c);
> > > > > >  ngx_int_t ngx_http_v3_init_session(ngx_connection_t *c);
> > > > > >  ngx_int_t ngx_http_v3_check_flood(ngx_connection_t *c);
> > > > > > +void ngx_http_v3_shutdown(ngx_connection_t *c);
> > > > > >  
> > > > > >  ngx_int_t ngx_http_v3_read_request_body(ngx_http_request_t *r);
> > > > > >  ngx_int_t 
> > > > > >