What happened if http timeout happened but the request is still sent out

[Xie Yuchen]

Hi, recently I wondered the question about what would happen if http timeout but the request is still sent out.

The motive is, let's assume we make a post request with a timeout. When timeout, the request is canceled, and the server won't serve it anymore.

 However, if the request is sent out when timeout, the server actually proceeds it anyway, which may make an unexpected error. 

So I would like to know how to avoid such an error. Do we need to additional check in the application layer, or could we check it inside the http library?

I triggered the timeout by debugger breakpoint in goland, I set the breakpoint at err = pc.bw.Flush() in writeLoop and n, err = w.pc.conn.Write(p).

In my opinion, the socket is closed once the timeout happens, and the  n, err = w.pc.conn.Write(p) will always fail as use of closed network connection.

However, the result is it could send out the bytes, I guess it's caused by the debugger, but have no idea about it.

[w54n]

If the connection to the server is lost while transmission, you will probably receive a broken pipe error.

If the timeout happens before sending data, nothing to care.

If the timeout happens during data transmission, well, you may have incomplete data(corrupted) in the server.

I don't think there is any way to prevent such thing in the std library itself. Your server must be capable to handle state properly, validate what it is receiving and decide if it should keep it or not, thus, yes, this is all application layer logic.

I think this all relates to how your server will treat idempotence and atomic writes. 

[Vladimir Varankin]

> If the connection to the server is lost while transmission, you will probably receive a broken pipe error.

> If the timeout happens before sending data, nothing to care.

> If the timeout happens during data transmission, well, you may have incomplete data(corrupted) in the server.

In addition to the cases above, there may be a situation when the server received the request fully, but didn't send the response back yet, and the client has dropped (e.g. timeouted).

I don't think there is "a correct" behaviour for that on the HTTP side. The application's parties (both client and server) must agree on their own rules for handling (or ignoring) such cases.