ioutil.ReadAll (response.Body) blokuje na zawsze - Golang

Question

tr := &http.Transport{ 
    TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, 
} 
client := &http.Client{Transport: tr} 
response, err := client.Get(link) 
if err != nil { 
    fmt.Println(err) 
} 
defer response.Body.Close() 

//block forever at the next line 
content, _ = ioutil.ReadAll(response.Body) 

Powyższy kod jest przeznaczony do odczytu treści ze strony internetowej, która znajduje się w pętli. Zauważyłem, że czasami linia ioutil.ReadAll(response.Body) będzie blokować na zawsze. Dzieje się tak losowo, jednak prawie zawsze dzieje się na tej stronie: http://xkcd.com/55. To bardzo interesujące, że gdy robię curl http://xkcd.com/55, to nic nie zwraca, jednak wget http://xkcd.com/55 zwraca całą stronę.

Answer 1

Twój kod powinien działać zgodnie z oczekiwaniami. Zgaduję, to jest problem z siecią. Spróbuj ustawić wyższy limit czasu.

package main 

import (
    "crypto/tls" 
    "fmt" 
    "io/ioutil" 
    "net/http" 
) 

func main() { 

    link := "http://xkcd.com/55" 

    tr := &http.Transport{ 
     TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, 
    } 
    client := &http.Client{Transport: tr} 
    response, err := client.Get(link) 
    if err != nil { 
     fmt.Println(err) 
    } 
    defer response.Body.Close() 

    //block forever at the next line 
    content, _ := ioutil.ReadAll(response.Body) 

    fmt.Println(string(content)) 

} 

Answer 2

Podejrzewam problem jest to, że starają się odczytać treść odpowiedzi, nawet jeśli wystąpi błąd:

if err != nil { 
    fmt.Println(err) 
} 

Należy też mieć else po tym, czy zalecana return lub continue lub coś jeszcze. Twoja linia ReadAll() jest niezdefiniowana.

(Jeśli pierwotnie skopiowane to z przykładowym kodem Get(), trzeba pamiętać, że zawiera log.Fatalf() w nodze błąd, który kończy program.)

Podejrzewam, że jak mówisz, czasami są coraz błąd sieciowy z tego czy innego powodu. Czy sprawdzasz dane wyjściowe dla wyniku Println()? W sposób, w jaki to zrobiłeś, mogłem sobie wyobrazić, że łatwo się w nim zakopuje.

Jak @twotwotwo zauważa, ten URL zwraca przekierowanie do tego samego adresu URL z końcowym ukośnikiem. Get() automatycznie obsłuży to za Ciebie, więc to nie jest problem. Domyślnie curl nie śledzi przekierowań podczas gdy wget robi. Możesz zobaczyć informacje o nagłówku, przekazując -i, aby zawinąć.

---

Inne rzeczy do sprawdzenia:

• Upewnij się defer jest faktycznie nazywa. Pamiętaj, że defer jest wywoływane na końcu funkcji, a nie na końcu bieżącego zakresu. Więc jeśli jesteś w pętli (jak wspomniałeś), po prostu zgromadzisz bloki defer i nigdy nie zamkniesz tych odpowiedzi.

• Jeśli serwer nigdy nie zamknie połączenia, io.ReadAll() nigdy nie wróci. To jest funkcja. Jeśli chcesz czas oczekiwania, musisz handle that yourself. Powinieneś być w stanie przetestować tę hipotezę za pomocą narzędzi takich jak curl. W niektórych rozwiązaniach, zobacz:

  • golang http timeout and goroutines accumulation
  • How to set timeout for http.Get() requests in Golang?
  • http.Transport.ResponseHeaderTimeout

Answer 3

Chyba znalazłem rozwiązanie dodając DisableKeepAlives: true, do `& http.Transport, tak:

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

Ponieważ dokonałem tej zmiany, nie spotkałem jeszcze żadnego długiego blokowania. Ale nie jestem w 100% pewien, czy to jest rozwiązanie. Zostawię nowy kod na jeden dzień lub dwa. Jeśli nie będzie blokowania, myślę, że ten problem został rozwiązany.

Answer 4

Dodatkowo uniknąć odczytać reakcja na ciało w ReadAll bez kontroli pamięci limitów/buforowe, na przykład:

googleResponse := GoogleResponse{} 
err = json.NewDecoder(io.LimitReader(resp.Body, MAX_MEMORY)).Decode(&googleResponse) 
if err != nil { 
    return nil, err 
} 

Więcej o nim w dobrych blogach:
Crossing Streams: a Love Letter to io.Reader by Jason Moiron
ioutil.ReadAll(httpResponse.Body) memory consumption
Golang Slices And The Case Of The Missing Memory