caddy: http2: read timeout applies to TCP connection and not requests; interrupts valid requests

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

Caddy 0.9.5

2. What are you trying to do?

Serve a ~900kiB javascript file.

3. What is your entire Caddyfile?

my.website.example.com
proxy / localhost:8080
tls {
    max_certs 1
}
log / stdout "{combined}"

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

• Ubuntu 16.04, Linux 4.4.0-62-generic, amd64.
• Amazon EC2 c4.xlarge instance.

Via systemd with the caddy file in /home/ubuntu/.caddy/Caddyfile.

[Unit]
Description=Caddy HTTP(s) server
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/.caddy
ExecStart=/home/ubuntu/.local/bin/caddy -agree
LimitNOFILE=1000000

[Install]
WantedBy=multi-user.target

5. What did you expect to see?

The javascript file should be served successfully. OR: errors in the log indicating a problem.

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

The log indicates no errors at all. However, the site intermittently does not load correctly. The network devtools indicate that the javascript started to be served, but some fraction (e.g, 400kiB or 700kiB) of the file is served before the devtools console shows GET https://my.example.com/js/bundle.js net::ERR_CONNECTION_RESET or net::ERR_CONNECTION_CLOSED.

I have tried this from three different ISPs (“network views”). It happens at different rates depending on the network, but it happens even on a decent ISP with wired connections. The rate there is something like 1/100 times. The caddy log appears to show a 200 success, but potentially with a truncated filesize.

Running caddy with -http2=false appears to fix the problem, or at least make it much rarer.

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

I’m unsure. It is a difficult to reproduce problem, on my good internet connection I couldn’t reproduce it at all. However, a client who was trying to test the website couldn’t get it to work, period. So I believe the rate at which the issue happens is dependent on the network quality.

I am not usually comfortable submitting bug reports without a reproduction case, but I searched through the bug tracker and saw nobody else has reported this issue yet, so I thought it was worth posting this.

I was unable to reproduce the issue with curl or nghttp at the command line from my good internet connection even after many hundreds of requests.

I have collected TCP dump logs and chrome://net-export which I will analyse and report back on if I am able to find the time.

Has anyone else encountered these issues? Is there a bug in the Go http/2 stack?