opened
lukenowak
username_0
### 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?
```text
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
Caddy does not reply with QUIC after USR1
issue
created
mholt
username_1
I've been able to reproduce it and am looking into it, however, might need some guidance from @username_2. 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.
comment
created
marten-seemann
username_2
I'll have a look at this issue tomorrow.
comment
created
mholt
username_1
We're both investigating this now! (Thanks for your help, Marten!)
comment
created
bprodoehl
username_3
I am still seeing this bug with 0.11.5. Did you guys happen to get anywhere in your investigation of the issue?
comment
created
hoswey
username_4
+1
comment
created
lukenowak
username_0
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?
comment
created
lukenowak
username_0
I was wrong, it does not work, I made wrong test :)
comment
created
mholt
username_1
Should be fixed in v2 now.
comment
closed
mholt
username_1
issue