When I change to a different URI (https://foo.com/bar) it works as
expected. So there's something with the original response that causes this
to not work. I'm curious as to what, but this is working as designed and
expected.
Thank you for the help!
--
You received this message because you are
Interesting. No headers coming back.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web
.98 is the client, .36 is the server.
This is the end of one transaction and the beginning of another. The client
sends a FIN-ACK, then immediately starts the next transaction with the SYN
packet. After that, the connection is ended; it looks like the client sends
the RST packet. I'll take a
In these situations I would normally use wireshark to look at the
life-cycle of a single session.
Which direction are the FIN and RST packets going?
Are they sent from the client, or the server?
If the RST packets are sent by the server - i.e. the server is slamming
shut the connection,
then the
This is what I did, and see no change in behavior.
for i := 0; i < 10; i++ {
response, err :=client.Get("https://foo.com";)
if err!= nil{
panic(err)
}
ioutil.ReadAll(response.Body)
response.Body.Close()
}
The network trace shows a SYN, SYN-ACK, ACK at the beginning of
Connections are indeed reused where possible by default in the Go standard
library.
But as http (before http2) does not support multiplexing, it is not
possible to reuse
a connection which is still in use (i.e. which is still in the process of
reading the response).
These means that the body of
