caddy -version)?Caddy 0.11.1 (non-commercial use only)
Access caddy with QUIC protocol after sending it USR1 signal
https://example.com:16443 {
bind 127.0.0.1
tls self_signed
}
./caddy -log stdout -quic &
Debian Jessie.
quic_client --disable-certificate-verification --host=127.0.01 --port=16443 https://example.com > /dev/null
kill -USR1 %1
quic_client --disable-certificate-verification --host=127.0.01 --port=16443 https://example.com > /dev/null
After sending USR1 signal I see such output in the output:
2018/12/18 10:26:46 [INFO] SIGUSR1: Reloading
2018/12/18 10:26:46 [INFO] Reloading
2018/12/18 10:26:46 [INFO] Reloading complete
2018/12/18 10:26:46 serving QUIC connections: server closed
Two times Request failed (404). as result of quic_client.
First Request failed (404)., then after sending USR1 to Caddy it ended with Failed to connect to 127.0.0.1:16443. Error: QUIC_NETWORK_IDLE_TIMEOUT
cat > Caddyfile
https://example.com:16443 {
bind 127.0.0.1
tls self_signed
}
^D
./caddy -log stdout -quic &
_Note_: My quic_client is client-linux-debug from https://github.com/lucas-clemente/quic-go
I've been able to reproduce it and am looking into it, however, might need some guidance from @marten-seemann. https://github.com/lucas-clemente/quic-go/issues/1743
It seems that the QUIC library does not assign a new "server" when it sees a new connection ID after the reloads.
I'll have a look at this issue tomorrow.
We're both investigating this now! (Thanks for your help, Marten!)
I am still seeing this bug with 0.11.5. Did you guys happen to get anywhere in your investigation of the issue?
+1
I just checked the behaviour with Caddy 1.0.0, and it seems QUIC correctly replies after SIGUSR1 and configuration reload. Is it only partially fixed or works by chance?
I just checked the behaviour with Caddy 1.0.0, and it seems QUIC correctly replies after SIGUSR1 and configuration reload. Is it only partially fixed or works by chance?
I was wrong, it does not work, I made wrong test :)
Should be fixed in v2 now.
Most helpful comment
I am still seeing this bug with 0.11.5. Did you guys happen to get anywhere in your investigation of the issue?