net/http: method decHostConnCount should not dec counter when somebody is block on connPerHostAvailable

[j2gg0s]

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

$ go version
go version go1.11.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env

What did you do?

About net/http/transport.getConn
When current conn number is greater than MaxConnPerHost, incHostConnCount return connPerHostAvailable and caller block on this chan, but connPerHostCount will not inc.
When somebody is block on connPerHostAvailable and one conn be closed, decHostConnCount notify and connPerHostCount dec.

One Example:

• MaxConnsPerHost is one

Time 1

• ReqA call getConn and get connA, connPerHostCount now is one

Time 2

• ReqB call getConn but block on connPerHostAvailable or idleConnCh

Time 3

• ReqA close connA, notify ReqB and dec connPerHostCount
• ReqB notify by idleConnCh and create connB

Time 4

• ReqC call getConn and create connC

current two conns exist, but MaxConnsPerHost is one.

What did you expect to see?

When somebody is block on connPerHostAvailable and one conn be closed, decHostConnCount notify and connPerHostCount don't dec.

[FiloSottile]

/cc @bradfitz

[j2gg0s]

Add one unit test to explain what I want to express.
#29910

[billybanfield]

Hey all! We appear to have run into this issue as well. It manifested as MaxConnsPerHost not being respected if concurrently made requests failed and then begin to succeed. Here's a repro demonstrating this behavior: https://github.com/billybanfield/tcpbug/blob/master/tcpbug.go. Happy to provide any additional info needed here.

Moving the decrement for connPerHostCount in transport.go as suggested by the original reporter fixes the issue.

[j2gg0s]

@bradfitz @FiloSottile Need some feedback.