Hi Yann, Am 09.12.2013 00:30, schrieb Yann Ylavic: > Now, if trying to send the first bytes of the request immediately fails > because the socket isn't connected anymore (e.g. EPIPE), you *know* that > exactly *none* bits of your current request reached the server. For this > reason it should be safe to retry by establishing a new connection to > the server and to try to send the request again over the newly > established connection. > > > The send() will never fail at this point if the peer FIN-closed the > connection (EPIPE or whatever on non-unixes), since it is only half-closed. > You can't read anymore, but you still can write, and this is precisely > why the error log is "error *reading* status line" and not "error > writing ...". > A second send() could fail however, though possibly with ECONNRESET, and > you are no better here. > > The point is that mod_proxy already checks whether the connection is > alive before trying to send a (successive) request on the kept alive > connection, by using a recv(MSG_PEEK) (see ap_proxy_is_socket_connected). > If that fails, a new connection is established and the request is sent > on it, this is already the current behaviour. > The race condition is when this check succeeds, but the peer closes the > connection before the request reaches it (in the meantime).
Okay, got that. If it really works like it should then I don't know how to improve the code. So the remaining question is, whether the checks whether the connection is alive are sufficient. Unfortunately I have no resources to investigate this any further. Regards, Micha
