Golang：在发送嵌套的HTTP请求时不断获取EOF

I have a client and two servers (both the servers in golang). All the solutions pertain to sending multiple requests from one server to another. But I am trying to implement this type of communication:

Client         Server A        Server B
Request1  -->  Received
               Request 2  -->  Received
               Received   <--  Request 3
               Response 3 -->  Received
               Received   <--  Response 2
Received  <--  Response 1

However, I am consistently getting the EOF error in the response to Request 2. I have read several articles on the topic, and tried all possible solutions but nothing has resolved this issue. Here is the code that I have written for sending the POST request. The same code is being called by both Server A and Server B.

func SendPost(url string, insecureSkipVerify bool, authHeader *CAuthHeader, contentType string, otherHeaders map[string]string, body string, v interface{}) (string, error) {
    bBody := strings.NewReader(body)
    req, err := http.NewRequest("POST", url, bBody)
    if err != nil {
        return "", utilities.GetError("01: ", err.Error())
    }
    req.Close = true

    if authHeader != nil {
        req.Header.Set(authHeader.GetHeaderStrings())
    }
    req.Header.Set(HEADERKEY_CONTENTTYPE, contentType)

    for k, v := range otherHeaders {
        req.Header.Set(k, v)
    }

    tr := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: insecureSkipVerify},
    }

    utilities.DebugLog("-------> SENDING POST: %s", url)
    netClient := &http.Client{Timeout: 40 * time.Second, Transport: tr}

    resp, err := netClient.Do(req)
    if err != nil {
        // GETTING ERROR LOG HERE IN REQUEST 2
        utilities.DebugLog("<------- RECEIVED POST: %s, with error: %s", url, err.Error())
        return "", utilities.GetError("02: ", err.Error())
    }
    defer resp.Body.Close()

    utilities.DebugLog("<------- RECEIVED POST: %s", url)
    b, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return "", utilities.GetError("03: ", err.Error())
    }

    utilities.DebugLog("%s", string(b))

    // MAY IGNORE THIS, JUST POPULATES THE RESPONSE INTO THE interface() PASSED AS A PARAMETER TO THIS FUNCTION
    if err := populateInterface(b, v); err != nil {
        return string(b), err
    }

    utilities.DebugLog("Received body: %s", string(b))

    return string(b), nil
}

The logs that I get on server A are:

2019-02-21 18:33:57.579758 +0530 IST m=+80.025904414: -------> SENDING POST: http://localhost:7350/v2/rpc/refreshPublicProfile?http_key=defaultkey
2019-02-21 18:34:13.517802 +0530 IST m=+95.963470623: <------- RECEIVED POST: http://localhost:7350/v2/rpc/refreshPublicProfile?http_key=defaultkey, with error: Post http://localhost:7350/v2/rpc/refreshPublicProfile?http_key=defaultkey: EOF

And the logs on Server B are:

2019-02-21 18:33:57.586869 +0530 IST m=+74.893470343: -------> SENDING POST: http://localhost:8103/publicprofile
2019-02-21 18:34:13.513541 +0530 IST m=+90.819664927: <------- RECEIVED POST: http://localhost:8103/publicprofile

Can the masters of golang http requests please help me understand what is the correct way of doing this?

The issue is not with golang http package, but with Server B, which is a third party server that doesn't send a response if the request runs for more than 10s. Thus the server A received the error as listed above. However, noteworthy learnings, both attributed to @JimB :

1. Minimal, Complete and Verifiable example proved to be extremely helpful since I ended up creating one and didn't observe the same error there. This led me to believe that the issue has to do with Server B, which is a third party application. I have submitted a bug with their team, who are looking into it now.

2. Have now constructed the transport using default values:

    tr := http.DefaultTransport.(*http.Transport)
    if tr.TLSClientConfig == nil {
        tr.TLSClientConfig = &tls.Config{InsecureSkipVerify: insecureSkipVerify}
    } else {
        tr.TLSClientConfig.InsecureSkipVerify = insecureSkipVerify      
    }

Turns out that this was a false alarm that I wasted a couple of days in. Unsure if this will help anyone, but still thought of posting the details of how this was resolved eventually.