net/http: TestClientTimeout_Headers_h2 prints message even without -v specified

[alexbrainman]

What version of Go are you using (go version)?

go version devel +96414ca Wed Dec 14 19:36:20 2016 +0000 windows/386

What operating system and processor architecture are you using (go env)?

set GOARCH=386
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=386
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:\dev
set GORACE=
set GOROOT=c:\dev\go
set GOTOOLDIR=c:\dev\go\pkg\tool\windows_386
set GCCGO=gccgo
set GO386=
set CC=gcc
set GOGCCFLAGS=-m32 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\DOCUME1\brainman\LOCALS1\Temp\go-build977159903=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2

What did you do?

go test -short -run=TestClientTimeout_Headers_h2 net/http

What did you expect to see?

PASS

What did you see instead?

2016/12/15 09:55:14 http: TLS handshake error from 127.0.0.1:1418: read tcp 127.0.0.1:1417->127.0.0.1:1418: use of closed network connection
PASS

Maybe there is something else to learn from that message being printed. I did not look into it to make a judgement.

Alex

[rakyll]

This message is coming from the server error log at https://github.com/golang/go/blob/master/src/net/http/server.go#L1726. Nothing unusual here.

[bradfitz]

Yeah, but the test shouldn't be spamming if that's expected. Most of our tests take care to be quiet and absorb log messages when they're spam. We can do that here too.

[bradfitz]

I can't reproduce this. We can reopen if we see it again.

@rakyll, in the future when linking to code, don't like to "master" URLs so line numbers stay put.

(Maybe we should have a gopherbot task that fixes those? Hmm.)

[rakyll]

@bradfitz Probably it too much work to consider gopherbot if this is not a common problem. We can think about it again once it is a big deal.