caddy/caddytest
tomholford 43adbee168 caddyhttp, reverseproxy: gate WebTransport behind enable_webtransport server flag
steadytao raised an architectural concern in review of #7669: the PR
put experimental WebTransport handling directly into Caddy's core
HTTP/3 accept path, so every HTTP/3 deployment paid for the feature
whether or not they used it.

Collapse the enablement surface to a single server-level opt-in that
matches Caddy's existing precedent for protocol-level features
(`protocols`, `allow_0rtt`, `enable_full_duplex`), and detect the
request shape at the handler the same way `reverse_proxy` detects a
WebSocket upgrade today — no per-handler config flag.

Core HTTP/3 path changes (modules/caddyhttp/server.go):
  * New `EnableWebTransport bool` field on Server, marked EXPERIMENTAL.
  * buildHTTP3Server now only calls webtransport.ConfigureHTTP3Server
    and sets EnableStreamResetPartialDelivery when the flag is true.
    When false, the constructed http3.Server is bit-for-bit identical
    to the pre-WebTransport implementation.
  * wtServer is constructed only when the flag is true.
  * serveH3AcceptLoop falls back to http3.Server.ServeListener when
    the flag is false — no varint peek, no per-connection dispatch.

Caddyfile wiring (caddyconfig/httpcaddyfile/serveroptions.go):
  * New `enable_webtransport` global server option, modeled on
    `enable_full_duplex`.

Reverse-proxy simplifications (modules/caddyhttp/reverseproxy/):
  * Removed HTTPTransport.WebTransport field and its Provision-time
    exclusivity check (no longer needed; H3 is validated separately).
  * Removed the `webtransport` Caddyfile subdirective under
    `transport http { }` — this neutralizes the prior commit that
    introduced it.
  * Removed Handler.webtransportEnabled cache. ServeHTTP now branches
    on isWebTransportExtendedConnect(r) alone, matching how the
    WebSocket upgrade branch works.
  * serveWebTransport gains fail-fast guards with clear errors when
    the parent server has enable_webtransport=false or when the
    handler's transport does not include HTTP/3.

Tests:
  * Existing TestServer_BuildHTTP3ServerEnablesWebTransport now sets
    EnableWebTransport=true explicitly; new
    TestServer_BuildHTTP3ServerWithoutWebTransport locks in the
    regression guard that flag-off produces the pre-PR http3.Server.
  * Integration tests updated: enable_webtransport: true added to
    every H3 server block; "webtransport": true dropped from the
    reverse_proxy transport JSON (auto-detected now).
  * Caddyfile adapt test for the deleted `webtransport` subdirective
    is removed; `enable_webtransport` is added to the existing
    global_server_options_single adapt test alongside its peers.

No runtime behavior change when enable_webtransport is false. Diff
against master on the core HTTP/3 path is effectively zero in that
configuration.
2026-06-23 19:04:24 +09:00
..
integration caddyhttp, reverseproxy: gate WebTransport behind enable_webtransport server flag 2026-06-23 19:04:24 +09:00
a.caddy.localhost.crt caddyhttp: Add default SNI tests (#3146) 2020-03-17 12:39:01 -06:00
a.caddy.localhost.key caddyhttp: Add default SNI tests (#3146) 2020-03-17 12:39:01 -06:00
caddy.ca.cer httpcaddyfile: Add client_auth options to tls directive (#3335) 2020-06-05 12:19:36 -06:00
caddy.localhost.crt caddyhttp: Fix default SNI for default conn policy (#3141) 2020-03-13 11:32:53 -06:00
caddy.localhost.key caddyhttp: Fix default SNI for default conn policy (#3141) 2020-03-13 11:32:53 -06:00
caddytest.go chore: clean up wording and typo fixes (#7745) 2026-05-20 16:36:30 +10:00
caddytest_test.go core: Check whether @id is unique (#7002) 2026-03-03 15:09:49 -07:00
leafcert.pem caddytls: clientauth: leaf verifier: make trusted leaf certs source pluggable (#6050) 2024-03-05 14:55:37 -07:00