It's uncommon to talk directly to a server these days, instead, we have proxies and load balancers along the way as well, and there are many reasons that a connection would get closed and you'd get an io.EOF. It's unlikely that the server received the request in this case, but it's possible, depending on how the proxies work.
You need to design API's with that in mind. On the server side, you must assume the client will retry, and so, you must reject duplicate requests. On the client side, you should retry everything except an HTTP/400 class error. It's now a common pattern that requests may include an idempotency token of some kind to aid the server in rejecting duplicates. -- Marcin On Mon, Dec 7, 2020 at 2:58 AM Gregor Best <b...@pferdewetten.de> wrote: > Hi! > > We're using a 3rd party provider's API to handle some of our customer > requests. Interaction with their API consists of essentially POST'ing > a small XML document to them. > > From time to time, `net/http`'s `Client.Do` returns an `io.EOF` > when sending the request. For now, the provider always reported > those instances as "we didn't get your request". > > Cursory search in various Github issues and a glance at the source > of `net/http` seems to indicate that `io.EOF` is almost always > caused by the server closing the connection, but the client not > getting the "it's now closed" signal before it tries to re-use the > connection. > > FWIW, `fasthttp`'s HTTP client implementation treats `io.EOF` as > "this request needs to be retried", but I don't know how much that > knowledge transfers to `net/http`. > > Is my interpretation of the situation correct? Or are there other > circumstances where the request _did_ end up at the remote end and > `io.EOF` is returned? > > I guess what I'm asking is: Is it safe (as in: requests won't end > up on the remote twice or more times) to retry POST requests when > `Client.Do` returns an `io.EOF`? > > Note that disabling connection reuse (as was suggested by a number > of stackoverflow posts) is an option that we'd like to avoid unless > there's absolutely no other way to handle this. > > -- > Gregor Best > b...@pferdewetten.de > > -- > 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 visit > https://groups.google.com/d/msgid/golang-nuts/a31d42a5-6a81-0579-a380-b268d10f4eb0%40pferdewetten.de > . > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LuS2KjHzgcHxkQyMqX6YELa3U3J2HYKz3vsP%3DrS%2Bct-8g%40mail.gmail.com.
