Golang: продолжайте получать EOF при отправке вложенных http-запросов

Question

У меня есть клиент и два сервера (оба сервера в golang).Все решения относятся к отправке нескольких запросов с одного сервера на другой.Но я пытаюсь реализовать этот тип связи:

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

Однако в ответ на запрос 2 я постоянно получаю ошибку EOF. Я прочитал несколько статей на эту тему и перепробовал все возможные решения.но ничто не решило эту проблему.Вот код, который я написал для отправки запроса POST.Сервер A и сервер 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
}

Журналы, которые я получаю на сервере A:

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

И журналы на сервере B:

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

Могут ли мастера http-запросов golang помочь мне понять, как правильно это сделать?

Answer 1

Проблема не в пакете golang http, а в сервере B, который является сторонним сервером, который не отправляет ответ, если запрос выполняется более 10 секунд.Таким образом, сервер A получил ошибку, как указано выше.Тем не менее, заслуживающие внимания уроки, оба приписанные @JimB:

1. Минимальный, Полный и Проверяемый пример, оказались чрезвычайно полезными, так как я в итоге создал один и не обнаружил там ту же ошибку.Это заставило меня поверить, что проблема связана с сервером B, который является сторонним приложением.Я отправил сообщение об ошибке их команде, которая сейчас ее изучает.

2. Теперь построили транспорт, используя значения по умолчанию:

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

Оказывается, это была ложная тревога, на которую я потратил пару дней. Не уверен, поможет ли это кому-нибудь, но все же подумал о том, чтобы опубликовать детали того, как это было решено в конечном итоге.