caddy: Infinite loop on goroutine with http.ResponseController changes

Not sure what happened - I was running master on this server for a while, last updated to commit e041962b66c45db8baab95b71a65f4c164736684 I believe. I got notified for the Caddy 2.7 release, I re-built it, and now HTTP/3 fails on this specific server by crashing on the first request it gets it seems to be crashing when encode is enabled and the client requests compression.

Caddy version is v2.7.0 h1:ZrAwnBzZ/FBoNw+WBlF2HER8oEs/O7c20ku6nbWFqco=, running on Fedora 38. Built using Go v1.20.7. (Past working build was on v1.20.6)

systemd[1]: Started caddy.service - Caddy.
caddy[69585]: runtime: goroutine stack exceeds 1000000000-byte limit
caddy[69585]: runtime: sp=0xc0209e0398 stack=[0xc0209e0000, 0xc0409e0000]
caddy[69585]: fatal error: stack overflow
systemd[1]: caddy.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
systemd[1]: caddy.service: Failed with result 'exit-code'.

---

The info below is now invalid, as it seems to be unrelated.

$ curl3 --http3 -v https://xxx
*   Trying xxx:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
*   Trying xxx:443...
*   Trying xxx:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* Connected to xxx (xxx) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
*  subjectAltName: host "xxx" matched cert's "xxx"
* Connected to xxx (xxx) port 443 (#0)
* using HTTP/3
* Using HTTP/3 Stream ID: 0 (easy handle 0x560045cd4db0)
> GET / HTTP/3
> Host: xxx
> User-Agent: curl/8.1.2
> Accept: */*
> 
zsh: terminated  curl3 --http3 -v https://xxx

(Not sure what’s up with my curl there - it eats all the RAM it can until the OOM killer terminates it. On Firefox it stays infinitely loading.)

The config isn’t something big, either:

xxx {
	import common

	header {
		X-Robots-Tag "none"
		-X-Powered-By
		-Server
	}

	header /api/collect {
		Access-Control-Max-Age "86400"
	}

	reverse_proxy 127.0.0.1:3000
}

common is merely this:

(common) {
	encode {
		zstd
		gzip
	}
}

HTTP/2 seems to be experiencing no crashes, only HTTP/3.