On Jun 28, 2017 16:58, "Patrick Hemmer" <hapr...@stormcloud9.net> wrote:
We instead need a way to differentiate (count) connections held open and sitting in the Lua delay function, and connections being processed by a server. My wishlist would be per-client queueing, sort of a source IP or XFF-based maxconn. How sweet would that be? Without addressing some potential issues with your solution, such as the potential for requests being handled out of order (#7 processes before #6 if it arrives after two of #1-#5 finish while #6 waits), it seems like maybe the http_first_req fetch would be useful? It's not a given that the redirect would reuse the same connection, but it might be worth a shot. http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#7.3.6-http_first_req Or, modify the query string for the redirect, to append another parameter (or create a query string if there isn't one). I have a setup that rewrites a 404 over to a 302 and adds a query string parameter to tell HAProxy to use a different backend for the subsequent request... I use this as a hackaround for the fact that we don't have a way for HAProxy to retain and resend idempotent [ Willy :) ] requests to a different backend (which would be another wishlist item for me) on certain errors. Same idea -- behave differently after a redirect than before it, even though the redirect sends the browser back to (essentially) the same URL. I redirect to the same base with ?action=refresh appended, which the proxy interprets to mean the request should route to the alternate backend.
