Commit Graph

4 Commits

Author SHA1 Message Date
Aradhya Jain
45ac7fe659 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 05:24:25 -07:00
Yong Tang
4382b80a35 core: upgrade Go requirement to 1.26.0 (#8466)
* core: upgrade Go requirement to 1.26.0

As golang 1.27 has been released, this PR
- Bump Go version requirement to 1.26.0
- Update Go build version to 1.27.0

This is also for solving the issue encountered in 8092 of k8s update

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

* Bump golang ci

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

* Fix

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

* Fix

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

* Fix

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

* Migrate faillint to forbidigo, as failint has not bee updated for more than a year

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>

---------

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
2026-09-10 19:34:44 -07:00
Ville Vesilehto
9f9aed31cf test: add t.Helper() calls to test helper functions (#7351) 2025-06-04 14:36:04 -07:00
Ville Vesilehto
efaed02c6a feat: limit concurrent DoQ streams and goroutines (#7296) 2025-05-18 17:49:21 -07:00