Thank you for filing this issue @DarthRamone and welcome to the Go project!

Could you perhaps please try to isolate a code snippet that illustrates the problem? Also could you check if the problem exists for Go1.13? You can get different Go versions using the tool dl

I shall also alert some experts about this issue, as we await a repro, cc @ianlancetaylor @cherrymui

Well, I rebuilt container with golang:1.13.11 image and played a little, and it worked well, but after some steps I've got EOF anyway. Plus I realised, that I forgot to comment DisableKeepAlives=true, so this flag is not even workaround, I think. Only difference - it works much longer and require slightly more intense requests to get EOF.

So issue exists at 1.13 as well, and DisableKeepAlives=true just helps to stay alive little longer, but doesn't fix anything. So maybe it's not about reusing connections at all, but the truth is somewhere near.

Providing code snippet maybe difficult, because I'm not sure how to exactly reproduce it. Even in worst case, when DisableKeepAlives set to false by default, I'm getting EOF not on every third call, but on every third certain call to certain endpoint. It may looks like API problem, but for some reasons it reproduces only on my RPi. I'm not sure I can figure out all conditions that causes this behaviour.

Gotcha, thanks @DarthRamone! To seed a reproduction, please take a look at this short program which creates an HTTPS server serving HTTP/1.1 traffic at https://play.golang.org/p/TaaJx_MJ2ad or inlined below

package main

import (
	"crypto/tls"
	"net/http"
	"net/http/httptest"
	"net/http/httputil"
	"time"
)

func main() {
	cst := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		conn, _, err := w.(http.Hijacker).Hijack()
		if err != nil {
			panic(err)
		}
		tcpConn := conn.(*tls.Conn)
		if true {
			<-time.After(100 * time.Millisecond)
		}
		tcpConn.Write([]byte("HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\nab\r\n\r\n"))
		tcpConn.Close()
	}))
	cst.StartTLS()
	defer cst.Close()

	println("Server address:", cst.URL)

	client := cst.Client()
	tr := client.Transport.(*http.Transport)
	tr.IdleConnTimeout = 50 * time.Millisecond
	for i := 0; i < 5; i++ {
		println("Request:", i, "*****")
		req, _ := http.NewRequest("GET", cst.URL, nil)
		res, err := client.Do(req)
		if err != nil {
			panic(err)
		}
		blob, err := httputil.DumpResponse(res, true)
		res.Body.Close()
		if err != nil {
			panic(err)
		}
		println(string(blob), "\n******\n\n")
	}
}

I intentionally have idleTimeouts and then invoke tcpConn.Close(), to kill/make some idle connections. Perhaps you can tweak this code to try to behave as your server is behaving?
If you need to just get back an EOF, please comment the line that sends back the HTTP response in the server and you'll be served back a straight up EOF.

One other tip, is that if you know the Telegram server is serving HTTP/2 traffic, you can use this environment flag GODEBUG=http2debug=2 which will print out for you logs e.g.

GODEBUG=http2debug=2 go run main.go

Kindly /cc-ing to your radar @bradfitz @fraenkel

I've changed your snipped a little to reproduce all what happens in bot library:
https://play.golang.org/p/tk0YnYy8gBv
But couldn't get EOF yet, only weird:
"Unsolicited response received on idle HTTP channel starting with "\r\n\r\n"; err=nil"
What's this btw?

I'll continue play with this snippet, maybe I will reproduce it somehow

UPD:
Fast google says that this weird error(weird for me) is somehow related to idle connections, https and all current subjects. There are even couple issues in golang repo about it

I believe this is related to #5312 - which was never fixed, just closed.

I've seen similar EOF behavior in my own code, which makes parallel requests using goroutines - it appears there's a race condition where Go will incorrectly reuse a terminated connection before that connection can be properly marked as "terminated" by the runtime.

Even though you're not using goroutines, I suspect you're hitting some aspect of that race condition.

It seems to be something that can crop up more frequently in resource-constrained environments - see this comment for a hypothesis as to what's happening: #5312 (comment)