2025-05-19 03:49:21 +03:00
|
|
|
package quic
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"fmt"
|
|
|
|
|
"strings"
|
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
|
|
"github.com/coredns/caddy"
|
|
|
|
|
"github.com/coredns/coredns/core/dnsserver"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
func TestQuicSetup(t *testing.T) {
|
|
|
|
|
tests := []struct {
|
|
|
|
|
input string
|
|
|
|
|
shouldErr bool
|
|
|
|
|
expectedMaxStreams *int
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
expectedMaxConnections *int
|
2025-05-19 03:49:21 +03:00
|
|
|
expectedWorkerPoolSize *int
|
|
|
|
|
expectedErrContent string
|
|
|
|
|
}{
|
|
|
|
|
// Valid configurations
|
|
|
|
|
{
|
|
|
|
|
input: `quic`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxStreams: nil,
|
|
|
|
|
expectedWorkerPoolSize: nil,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxStreams: nil,
|
|
|
|
|
expectedWorkerPoolSize: nil,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams 100
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedMaxStreams: new(100),
|
2025-05-19 03:49:21 +03:00
|
|
|
expectedWorkerPoolSize: nil,
|
|
|
|
|
},
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections 50
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxConnections: new(50),
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections 0
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxConnections: new(0),
|
|
|
|
|
},
|
2025-05-19 03:49:21 +03:00
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size 1000
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxStreams: nil,
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedWorkerPoolSize: new(1000),
|
2025-05-19 03:49:21 +03:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams 100
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
max_connections 50
|
2025-05-19 03:49:21 +03:00
|
|
|
worker_pool_size 1000
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedMaxStreams: new(100),
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
expectedMaxConnections: new(50),
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedWorkerPoolSize: new(1000),
|
2025-05-19 03:49:21 +03:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
# Comment
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: false,
|
|
|
|
|
expectedMaxStreams: nil,
|
|
|
|
|
expectedWorkerPoolSize: nil,
|
|
|
|
|
},
|
|
|
|
|
// Invalid configurations
|
|
|
|
|
{
|
|
|
|
|
input: `quic arg`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams abc
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "invalid max_streams value",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams 0
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "positive integer",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams -10
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "positive integer",
|
|
|
|
|
},
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections abc
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "invalid max_connections value",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections -10
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "non-negative integer",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections 50
|
|
|
|
|
max_connections 100
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "already defined",
|
|
|
|
|
expectedMaxConnections: new(50),
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_connections 100 200
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
2025-05-19 03:49:21 +03:00
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size abc
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "invalid worker_pool_size value",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size 0
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "positive integer",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size -10
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "positive integer",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams 100
|
|
|
|
|
max_streams 200
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "already defined",
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedMaxStreams: new(100),
|
2025-05-19 03:49:21 +03:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size 1000
|
|
|
|
|
worker_pool_size 2000
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "already defined",
|
2026-09-10 19:34:44 -07:00
|
|
|
expectedWorkerPoolSize: new(1000),
|
2025-05-19 03:49:21 +03:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
unknown_directive
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "unknown property",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
max_streams 100 200
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
input: `quic {
|
|
|
|
|
worker_pool_size 1000 2000
|
|
|
|
|
}`,
|
|
|
|
|
shouldErr: true,
|
|
|
|
|
expectedErrContent: "Wrong argument count",
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for i, test := range tests {
|
|
|
|
|
c := caddy.NewTestController("dns", test.input)
|
|
|
|
|
err := setup(c)
|
|
|
|
|
|
|
|
|
|
if test.shouldErr && err == nil {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected error but found none", i, test.input)
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
if !test.shouldErr && err != nil {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected no error but found: %v", i, test.input, err)
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if test.shouldErr && !strings.Contains(err.Error(), test.expectedErrContent) {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected error containing '%s', but got: %v",
|
|
|
|
|
i, test.input, test.expectedErrContent, err)
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if !test.shouldErr || (test.shouldErr && strings.Contains(test.expectedErrContent, "already defined")) {
|
|
|
|
|
config := dnsserver.GetConfig(c)
|
|
|
|
|
assertMaxStreamsValue(t, i, test.input, config.MaxQUICStreams, test.expectedMaxStreams)
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
assertMaxConnectionsValue(t, i, test.input, config.MaxQUICConnections, test.expectedMaxConnections)
|
2025-05-19 03:49:21 +03:00
|
|
|
assertWorkerPoolSizeValue(t, i, test.input, config.MaxQUICWorkerPoolSize, test.expectedWorkerPoolSize)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// assertMaxStreamsValue compares the actual MaxQUICStreams value with the expected one
|
|
|
|
|
func assertMaxStreamsValue(t *testing.T, testIndex int, testInput string, actual, expected *int) {
|
2025-06-05 00:36:04 +03:00
|
|
|
t.Helper()
|
2025-05-19 03:49:21 +03:00
|
|
|
if actual == nil && expected == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (actual == nil) != (expected == nil) {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICStreams to be %v, but got %v",
|
|
|
|
|
testIndex, testInput, formatNilableInt(expected), formatNilableInt(actual))
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if *actual != *expected {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICStreams to be %d, but got %d",
|
|
|
|
|
testIndex, testInput, *expected, *actual)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
plugin/quic: add max_connections directive (#8610)
* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
2026-10-08 17:54:25 +05:30
|
|
|
// assertMaxConnectionsValue compares the actual MaxQUICConnections value with the expected one
|
|
|
|
|
func assertMaxConnectionsValue(t *testing.T, testIndex int, testInput string, actual, expected *int) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
if actual == nil && expected == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (actual == nil) != (expected == nil) {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICConnections to be %v, but got %v",
|
|
|
|
|
testIndex, testInput, formatNilableInt(expected), formatNilableInt(actual))
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if *actual != *expected {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICConnections to be %d, but got %d",
|
|
|
|
|
testIndex, testInput, *expected, *actual)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-05-19 03:49:21 +03:00
|
|
|
// assertWorkerPoolSizeValue compares the actual MaxQUICWorkerPoolSize value with the expected one
|
|
|
|
|
func assertWorkerPoolSizeValue(t *testing.T, testIndex int, testInput string, actual, expected *int) {
|
2025-06-05 00:36:04 +03:00
|
|
|
t.Helper()
|
2025-05-19 03:49:21 +03:00
|
|
|
if actual == nil && expected == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (actual == nil) != (expected == nil) {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICWorkerPoolSize to be %v, but got %v",
|
|
|
|
|
testIndex, testInput, formatNilableInt(expected), formatNilableInt(actual))
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if *actual != *expected {
|
|
|
|
|
t.Errorf("Test %d (%s): Expected MaxQUICWorkerPoolSize to be %d, but got %d",
|
|
|
|
|
testIndex, testInput, *expected, *actual)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func formatNilableInt(v *int) string {
|
|
|
|
|
if v == nil {
|
|
|
|
|
return "nil"
|
|
|
|
|
}
|
|
|
|
|
return fmt.Sprintf("%d", *v)
|
|
|
|
|
}
|
|
|
|
|
|
2026-09-10 19:34:44 -07:00
|
|
|
//go:fix inline
|