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.
