I have the same problem with goquery.NewDocumentFromReader (godoc), passing an http.Response.Body to it.

So far it happened a few times on Windows 10 Pro, 64bit after at least one day program runtime.

I'm using Go version go1.8.1 linux/amd64 on Debian.

Output of go env:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/christian/Projects/go"
GORACE=""
GOROOT="/usr/lib/go-1.8"
GOTOOLDIR="/usr/lib/go-1.8/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build016880156=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

Compiling for Windows with: env GOOS=windows GOARCH=amd64 go build -o bin/windows_amd64/mdl-client.exe

INTERNAL_ERROR is from https://http2.github.io/http2-spec/#rfc.section.7 ... it's when the server says INTERNAL_ERROR.

It's not the Go http2 package getting confused itself. We're just relaying what we heard.

I'm afraid there's nothing actionable here. If there were at least a repro then we can start to guess at a) which server is saying this, and b) why that server is getting confused.

/cc @tombergan

Sadly I cannot provide a repository, since my project is not open source, but here is at least the (shortened) code leading to the error:

resp, err := http.Get(url)
if err != nil || resp.StatusCode != 200 {
	// Retry or abort
	return
}
doc, err := goquery.NewDocumentFromReader(resp.Body)
if err != nil {
	log.Printf("Parsing HTML from %s failed: %s. HTTP Status: %s", url, err.Error(), resp.Status))
}

This prints something like Parsing HTML from https://[…] failed: stream error: stream ID 1847351; INTERNAL_ERROR. HTTP Status: 200 OK

What confuses me is that this happens while getting a 200 OK. I made sure it does not try to read the body when getting other status codes - the code above is heavily shortened, but ultimately has the same effect.

I modified the code to be more verbose next time, but since this happens rarely it might take a while…

@fanirthuban, that means the server replied with HEADERS (with a 200) and then while it was streaming the body, the server had an INTERNAL_ERROR and told you.

@jba should escalate with internal teams to debug.

And I thought the whole response is read before http.Get returns... This might me worth mentioning in the documentation of net/http.

@fanirthuban, I filed #22873 for that.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@bradfitz / @jba : I am facing the same issue as reported in the issue.

Have created a gist on how to reproduce the issue.

https://gist.github.com/sks/86cff171ec34b15261ae534e8353dc14#file-readme-md

Initial finding:

• Always reproducible on slow connections.

Please let me know in case any further details are required from my side.

--Thanks

@sks, this issue is closed and doesn't shut up in any of our dashboards.

Also, this issue seems unrelated to yours.

Open a new bug if you've found something new, and include details of what versions of things you're using.

Thanks @bradfitz : Created #26338