'Error in the HTTP2 framing layer' after goaway

[TvdW]

I did this

A request to a HTTP/2 server that was restarting resulted in a "Error in the HTTP2 framing layer" message despite the server behaving correctly. Further investigation shows that in the case of a GOAWAY frame with a fully processed 204 "No content" response the GOAWAY wins and an error is returned.

I expected the following

Since the response was received in its entirety, there should be no error. The connection should then be closed (since there was a GOAWAY frame).

curl/libcurl version

$ ./bin/curl -V
curl 7.66.0-DEV (x86_64-unknown-linux-gnu) libcurl/7.66.0-DEV OpenSSL/1.0.2k-fips zlib/1.2.7 brotli/1.0.1 c-ares/1.15.0 nghttp2/1.39.1
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS brotli Debug HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TrackMemory UnixSockets

steps to reproduce

I have this little Go program that runs a webserver to return a 204 while also sending a goaway frame: https://gist.github.com/TvdW/4d12fc00f91175e379b15a079319d000 (running as while ./test; do true; done)

For simplicity, I also have it running at https://domisc-01.server.tvdw.eu/

$ ./bin/curl https://domisc-01.server.tvdw.eu/
curl: (16) Error in the HTTP2 framing layer

[TvdW]

Just to be sure:

• This happens with a different non-Go webserver as well (the nghttp2-based Envoy server)
• Firefox is able to request the URL successfully, curl gets an error

[TvdW]

This initially only looked reproducible for a 204, but further testing shows it also happens on a 200, so I've updated the code to do that instead (keep it as simple as possible, etc)

[bagder]

Yeah, I think it is entirely response code agnostic. I have a local fix that I'm testing, pull request coming up soon.