This series adds support for flood detection in QUIC and HTTP/3 smilar to
HTTP/2.
- patch 1 removes client-side encoder support from HTTP/3 for simplicity
- patch 2 fixes a minor issue with $request_length calculation
- patch 3 adds HTTP/3 traffic-based flood detection
- patch 4 adds QUIC traf
# HG changeset patch
# User Roman Arutyunyan
# Date 1633520939 -10800
# Wed Oct 06 14:48:59 2021 +0300
# Branch quic
# Node ID d53039c3224e8227979c113f621e532aef7c0f9b
# Parent 1ead7d64e9934c1a6c0d9dd3c5f1a3d643b926d6
HTTP/3: removed client-side encoder support.
Dynamic tables are not used
# HG changeset patch
# User Roman Arutyunyan
# Date 1633521076 -10800
# Wed Oct 06 14:51:16 2021 +0300
# Branch quic
# Node ID 1b87f4e196cce2b7aae33a63ca6dfc857b99f2b7
# Parent d53039c3224e8227979c113f621e532aef7c0f9b
HTTP/3: fixed request length calculation.
Previously, when request was bl
# HG changeset patch
# User Roman Arutyunyan
# Date 1633602162 -10800
# Thu Oct 07 13:22:42 2021 +0300
# Branch quic
# Node ID 31561ac584b74d29af9a442afca47821a98217b2
# Parent 1b87f4e196cce2b7aae33a63ca6dfc857b99f2b7
HTTP/3: traffic-based flood detection.
With this patch, all traffic over
# HG changeset patch
# User Roman Arutyunyan
# Date 1633602816 -10800
# Thu Oct 07 13:33:36 2021 +0300
# Branch quic
# Node ID e20f00b8ac9005621993ea19375b1646c9182e7b
# Parent 31561ac584b74d29af9a442afca47821a98217b2
QUIC: traffic-based flood detection.
With this patch, all traffic over a
# HG changeset patch
# User Roman Arutyunyan
# Date 1633603050 -10800
# Thu Oct 07 13:37:30 2021 +0300
# Branch quic
# Node ID 25aeebb9432182a6246fedba6b1024f3d61e959b
# Parent e20f00b8ac9005621993ea19375b1646c9182e7b
QUIC: limited the total number of frames.
Exceeding 1 allocated frame
On Thu, Oct 07, 2021 at 02:36:13PM +0300, Roman Arutyunyan wrote:
> This series adds support for flood detection in QUIC and HTTP/3 smilar to
> HTTP/2.
>
> - patch 1 removes client-side encoder support from HTTP/3 for simplicity
> - patch 2 fixes a minor issue with $request_length calculation
>
Hello!
On Wed, Oct 06, 2021 at 07:53:00PM +, Eran Kornblau wrote:
> >
> > -Original Message-
> > From: nginx-devel On Behalf Of Maxim Dounin
> > Sent: Wednesday, 6 October 2021 16:12
> > To: nginx-devel@nginx.org
> > Subject: Re: Sending a notification to the main nginx thread
> >
Hello!
On Thu, Oct 07, 2021 at 03:16:37PM +, Eran Kornblau wrote:
> > -Original Message-
> > From: nginx-devel On Behalf Of Maxim Dounin
> > Sent: Thursday, 7 October 2021 16:07
> > To: nginx-devel@nginx.org
> > Subject: Re: Sending a notification to the main nginx thread
> >
> > He
I haven't played with them myself, but have considered sub-requests? Since
your are using a library with its own event-loop, perhaps it's best to run
it in its own process and use nginx sub-requests to bridge the two
processes? Seems doable.
https://nginx.org/en/docs/dev/development_guide.html#http
> -Original Message-
> From: nginx-devel On Behalf Of Maxim Dounin
> Sent: Thursday, 7 October 2021 16:07
> To: nginx-devel@nginx.org
> Subject: Re: Sending a notification to the main nginx thread
>
> Hello!
>
> To re-iterate: inside a "side thread" you are not allowed to call any
> non
Hello,
I use nginx as a proxy with enabled cache. I encountered strange
behavior on revalidate.
When upstream does not return any caching headers it is ok - file is
cached with default cachetime and on revalidate the r->cache->valid_sec
is updated to now + default cachetime.
Also when upst
>
> -Original Message-
> From: nginx-devel On Behalf Of Maxim Dounin
> Sent: Thursday, 7 October 2021 20:17
> To: nginx-devel@nginx.org
> Subject: Re: Sending a notification to the main nginx thread
>
>
> Hello!
>
> In no particular order:
>
> - Assuming nginx uses only POSIX function
13 matches
Mail list logo