Hi, On Tue, Jan 15, 2013 at 09:34:37AM +0100, Cyril Bonté wrote: > Le 15/01/2013 09:24, Willy Tarreau a écrit : > >On Tue, Jan 15, 2013 at 09:09:22AM +0100, Cyril Bonté wrote: > >>Hi Igor, > >> > >>Le 15/01/2013 09:00, Igor a écrit : > >>>Hi, conf like: > >>> > >>>listen admin > >>> bind 127.0.0.1:11199 > >>> stats enable > >>> stats hide-version > >>> stats uri /ha-stats > >>> stats realm Ha\ statistics > >>> stats auth admin:admin > >>> stats refresh 60s > >>> stats admin if TRUE > >>> > >>>I will try remove password to check that. > >> > >>You forgot to provide the defaults section. > >>It's important, to see if you're not missing some options such as > >>"http-server-close" or "httpclose", which could explain your 503. > > > >Agreed. Anyway this would be a bug because the stats page works in > >close mode. But it is still possible. > > I was thinking of a /favicon.ico downloaded by the browser that could > leave the connection in keep-alive during the POST request but if > there's no server behind, even a favicon.ico should reply with a 503 in > close mode.
I have made some tests and came to the same conclusions here. I cannot reproduce the issue at all, but the first favicons did cause some 503 to be logged. Another possibility would be that the redirect performed after the POST would contain a wrong URL or at least one that is not caught by haproxy upon next request, but I don't see why that would happen. Does your browser access haproxy directly or are you passing via another reverse-proxy (eg: apache, haproxy, ...) ? If the URL is rewritten by another front proxy then the issue could come from this URL not always been properly rewritten (imagine an haproxy running in tunnel mode and doing the rewrite). A last case would be that the browser sometimes emits a request with a method that is none of GET/HEAD/POST (eg: OPTIONS). This method is not intercepted by haproxy for the stats page and tries to go to the server. I think that some logs of the faulty requests will substantially help here. Regards, Willy
