Caddy: Caddy does not reply with QUIC after USR1

Created on 18 Dec 2018  路  8Comments  路  Source: caddyserver/caddy

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.1 (non-commercial use only)

2. What are you trying to do?

Access caddy with QUIC protocol after sending it USR1 signal

3. What is your entire Caddyfile?

https://example.com:16443 {
  bind 127.0.0.1
  tls self_signed
}

4. How did you run Caddy (give the full command and describe the execution environment)?

./caddy -log stdout -quic &

Debian Jessie.

5. Please paste any relevant HTTP request(s) here.

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

6. What did you expect to see?

Two times Request failed (404). as result of quic_client.

7. What did you see instead (give full error messages and/or log)?

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

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

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

bug

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?

All 8 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

whs picture whs  路  3Comments

billop picture billop  路  3Comments

SteffenDE picture SteffenDE  路  3Comments

mikolysz picture mikolysz  路  3Comments

dafanasiev picture dafanasiev  路  3Comments