Verify HTTP/3 (QUIC) over the socket-activated fd after applying #81 #101
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-infra#101
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "%!s()"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Post-apply verification for #81 / PR #94. The socket-activation change binds HTTP/3 (QUIC) via
ListenDatagram=443incaddy.socket→bind fdgram/4 { protocols h3 }in the Caddyfile. This path could not be exercised in the local podman machine (nocurl --http3there), so it's verified only by config-validation, not end-to-end.Once PR #94 is applied to prod, confirm HTTP/3 actually works over the inherited datagram fd:
h3) againsthttps://www.gitborg.seandhttps://git.gitborg.se, orcurl --http3 -sI https://www.gitborg.seif a HTTP/3-capable curl is available.alt-svc: h3=":443"response header is advertised.Fallback if h3 misbehaves over the inherited fd: drop the
ListenDatagram=443line fromcaddy.socketand thebind fdgram/4 { protocols h3 }block from the(socket_bind)Caddyfile snippet — Caddy falls back to HTTP/1.1 + HTTP/2 on fd/3 with no other change. Track the outcome here (either close as verified, or open a fix if the fd path needs adjustment).Partial verification after the #94 apply to prod (2026-07-18):
alt-svc: h3=":443"; ma=2592000advertised on https://www.gitborg.se.failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). HTTP/3 works, but throughput is capped untilnet.core.rmem_max/wmem_maxare raised (https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes). Candidate: add the sysctl to the base/podman role.curl --http3) to fully close this.Net: h3 is offered and the listener is healthy; remaining = (1) confirm a real h3 handshake, (2) decide on the UDP-buffer sysctl.
Verified — HTTP/3 does not work on prod (root cause found)
Drove an HTTP/3-only client (
curl --http3-only, badouralix/curl-http3 image) from a container against prod:Control (same image/host):
cloudflare-quic.comandgoogle.com→ http_version=3 code=200. So the client/egress is fine — prod's h3 is genuinely broken, not a test artifact.Root cause: UDP/443 is not open at the perimeter. The ingress model is TCP-only:
roles/base/templates/nftables.conf.j2renderstcp dport …fromgitborg_ingress_tcp_ports;opentofu/security.tofurenders the Neutron SG withprotocol = "tcp"from the same list.So inbound QUIC (UDP/443) is dropped at both the host firewall and the OpenStack SG. This predates #81 (the pre-#81
PublishPort=443/udpbound the container, but the perimeter still filtered UDP) — #81 carried forward a never-working h3. Net effect today: Caddy advertisesalt-svc: h3=":443", clients attempt h3, fail, and fall back to h2 — a small connection-setup penalty for zero benefit.Decision needed — enable or disable h3
ingress_tcp_portsshape + nftables template +security.tofu), then apply base + tofu (an SG change — handle carefully per infra-apply). Cost: a new public UDP port (attack surface), firewall + SG change.ListenDatagram=443fromcaddy.socket+ thebind fdgram/4 { protocols h3 }from the Caddyfile so Caddy stops advertising a filtered protocol — honest h1/h2-only. This is this issue's own documented fallback. Cheapest, least-privilege, and h2 is entirely sufficient for a git host + portal.