> You can't retry all the requests (particularly non idempotent ones), not even once. > Suppose it is a charged $100 order, you wouldn't like any proxy to double that because of network problems...
I'm not talking about retrying requests but retrying writing on the socket after trying to "re-"open a connection. When mod_proxy tries to forward the client request to the backends and encounters a closed connection due to the described race condition it will fail back to the client. Instead, I suggest trying to re-open the connection once and then either send the client request over that connection or go back to the client with an error. No double-sending requests anywhere. > Same as above, this can't be done (even less at the connection level). > There is really no overall solution, IMHO. I doubt that statement is correct. As I said before, I've seen it work with another proxy so the basic approach is no problem. You might be correct in that it's not possible with apache but I cannot confirm or disconfirm this until I have tried adding it. Anyway, this is getting us nowhere until I (or anyone) come(s) up with a corresponding patch. I hope I'll get around for it sometime until January. Until then I'll just see this as declined. On Thu, Dec 5, 2013 at 5:26 PM, Yann Ylavic <[email protected]> wrote: > On Thu, Dec 5, 2013 at 5:04 PM, Thomas Eckert <[email protected] > > wrote: > >> > It also seems that it adds more cycles to Apache on the front to >> > reduce a race condition that can't really be removed. >> >> While it's true that the race condition itself cannot be avoided we can >> definitely work around the resulting problem situation, e.g. by trying to >> open the connection again once and then either send the data or fail back >> to the client as we do right now. The approach itself is not theoretical: I >> know that's exactly how certain forward proxies solve the problem. >> >> > You can't retry all the requests (particularly non idempotent ones), not > even once. > Suppose it is a charged $100 order, you wouldn't like any proxy to double > that because of network problems... > > > >> >> >> > Plus, if we do this here, shouldn't we do it for >> > all proxy protocol submodules (fcgi, etc...)? >> >> I go with my original suggestion: Have the above mentioned retry-once >> mechanism apply on connection level so that request modules don't even >> notice. Otherwise I would agree in having it added to the appropriate >> modules. I would like to come up with the appropriate patch but I doubt >> I'll have the time for it anytime soon :-( >> > > Same as above, this can't be done (even less at the connection level). > There is really no overall solution, IMHO. > > >> >> As it stands I think Yann's approach in "flushing through the reverse >> proxy" is better then doing nothing. Though I expect that to be useless for >> a lot of deployments where stuff like AV scanning or mod_security will need >> to buffer the request bodies - then you will have the original problem >> again. >> >> > My first approach was to flush only, but the latest patch take also care > about buffered request, the backend won't be connected/reused until the > bytes are in mod_proxy. > >
