Retries and body

[jonasfj]

Seems broken if retries is used with body, as io.Reader won't rewind...

I haven't tried it... but that seems problematic... Maybe it's better to not support streams to avoid bugs.

Or am I missing something?

[lafikl]

Hi, I don't think that it'll be an issue because it's reusing the same request object, and if for some reason the server isn't reachable then it won't be able to send the request, therefore it won't read the io.Reader.

If you can post the code you using, it would be better.

Thanks.

[jonasfj]

I haven't tried it yet... So feel free to close the issue :) The subtle timing dependent http/tcp issues can be very hard to reproduce... So I look for them before I use a library.

But, if the TCP connection is broken half way through streaming the request it seems all is lost... As io.Reader is mutable.

When hacking node, and dealing with TCP connection pooling which go does too... I happens that a TCP connection is kept alive, but really the remote end is dropped silently by server because of arbitrary timeout, etc. With some bad timing you'll be sending the request on to a TCP socket that's dead. The OS and by implication go won't know that the TCP connection is dead until it sends the next package.

It's standard practice for azure storage services to drop connections silently after 60 seconds. It feels bad, on the other hand it's really smart that it forces us to deal with the worst case scenario. As not doing so leads to unstable systems in any case.

Note: I don't have solution, short of simply not claiming to do retries for sending streams.. If sending binary things with retries, using []byte for seems like the only safe choice to me. Or io.ReadSeeker.