error page problem
Hello All, I was trying to configure custom error pages on haproxy but after waisting a lot of time I'm not successful. I wanted to serve it all the time as my backends give it to the clients. I put the following directive in my config file: errorfile 500 /etc/haproxy/errorfiles/err.http in defults and "listen" section and all the time it fails. The file exist and it looks like this: 500 Internal Server Error The server encountered an internal error or misconfigurationand was unable to complete your request. Please contact the server administrator, a...@s.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. I'm little fed up of it, probably I'm doing sth wrong. Need some tips! Thanks -- Regards. Mikołaj
Re: error page problem
Hello Mikolaj, Mikołaj Radzewicz schrieb am 13.04.2010 12:47: > I put the following directive in my config file: > errorfile 500 /etc/haproxy/errorfiles/err.http > in defults and "listen" section and all the time it fails. > The file exist and it looks like this: > > > The file referenced by "errorfile" must not be a html-file, but a "http"-file because the file is returned verbatim on the TCP socket. Try to put this at the top of your current /etc/haproxy/errorfiles/err.http and reload haproxy: HTTP/1.0 500 Internal Server Error Cache-Control: no-cache Connection: close Content-Type: text/html or have a look at the example errorfiles in the source tarball and doc for "errorfile". Thomas
Re: appsession not working in url (1.3.22, 1.3.24)
Hi, thanks for the reply Willy + Cyril. Am 09.04.2010 22:43, schrieb Cyril Bonté: > Hi, > > Le vendredi 9 avril 2010 20:21:24, Willy Tarreau a écrit : >>> With 1.3.22 and .24 I just get the "manage_server_side_cookies". When I >>> constantly deny the cookie, >>> the requests are round robbed, while with 1.4.4 they are sticky from the >>> first request on, because >>> the url appsession lookup in the url is working. >> >> Could you please also include a dump of the exchange between the client and >> haproxy (or even an output of "haproxy -d") ? It is possible that something >> appears mangled and that we're not thinking about it. >> >>> Will this be fixed in 1.3.x or do you suggest to upgrade to 1.4? >> >> No, there is no reason to upgrade for something that ought to work. 1.3 is >> still maintained, so if it is supposed to work and it doesn't, it's a bug >> and it needs to be fixed. If the fix is too dangerous, we may reconsider >> this but right now this has not been qualified yet. However, you can use >> 1.4 as a workaround (or maybe you plan to upgrade for other reasons). > > Well, no this is not really a bug. > HAProxy 1.3.x only parses the path parameters, behind a semicolon (and only > the first one), > like http://test/cookie.php;jsessionid=x?querystring This explains the behaviour, so I guess debugging output (hash table dump) is not required. Is the cookie name in appsession case insensitive? when it's matched in the url? > > The only "bug" is that the documentation says it checks the query string, > which is not true. > That's why I added a mode to appsession in one of the 1.4.x patch, which > allows to choose between path parameters and the query string. Will this be backported to 1.3.x or can this patch be safely applied to 1.3? This sounds like a great thing to have in 1.3. > > http://haproxy.1wt.eu/git?p=haproxy-1.4.git;a=commit;h=b21570ae0f5024b86b72762a519972fbce5b307e > > Now, what I don't understand : why your JSESSIONID parameter is in the query > string ? which server do you use to allow that ? > That's easily explained: I'm using a very short piece of php and decided to name the variable JSESSIONID. Of course, this might cause some confusion. Thanks for sharing your experience with cookies, Willy. I can't belive that a site with 2M visitors per day doesn't even has a single security obsessed visitor that turned off cookies completely. I agree on this, it's just a requirement in a project. > Multiple sticks are supported though right now we can only stick on IP > addresses. Is this something that will be implemented in 1.4 or are you talking about 1.3 vs. 1.4 when you say it's not supported right now? Is there a place to read about the precedence of the different methods (cookie, appsession, balance)? Best, Michael
Question on healtchecks
I have an active-passive HAProxy setup using keepalived, similar to this: http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-keepalived-on-debian-lenny My question is, is there any way to have the healtchecks performed on only the active HAProxy? Currently both the active and passive HAProxys ping my servers every 3 seconds at (almost) the same time. I have enabled the spread-check option with a value of 5 but it seems to make little difference. Is there anything I can do to remedy this problem? Thanks!
help
help
Re: error page problem
Hi Mikołaj, On 2010-04-13 12:47, Mikołaj Radzewicz wrote: > I was trying to configure custom error pages on haproxy but after > waisting a lot of time I'm not successful. I wanted to serve it all > the time as my backends give it to the clients. if I understand you correct you want to check if one of your backends returned a HTTP 500 and replace its response to the client with the errorfile in haproxy. This is actually not possible. The errorfile and errorloc parameters only apply for error generated by Haproxy itself. So the file specified in errorfile 500 ... is only served if Haproxy itself had an internal error. You have to fix your application error pages instead. Also as Thomas noted, the configured errorfiles are in HTTP format. Thus at least you would have to add the appropriate HTTP headers. Be sure to use the correct linebreaks (\n\r) --Holger
"timeout client" weird behaviour in 1.3.22
I upgraded from 1.3.15 (lenny) to 1.3.22 (lenny-backports) and "timeout client X" now seems to close connections at X even if client continuously sends something. I can reproduce it with "timeout client 10s" and manually telnet and continuously type: I get disconnected after 10 seconds whatever I do. With 1.3.15 I only get disconnected after 10 seconds of inactivity. With 1.3.22 I get disconnected after 10 seconds, whatever happens. I also reproduce the same behaviour with 1.3.24. Is there a bug with "timeout client" that has been introduced between 1.3.15 and 1.3.22? -- Cyril Bouthors
RE: Question on healtchecks
> -Message d'origine- > De : Static Void [mailto:static.void@gmail.com] > Envoyé : mardi 13 avril 2010 16:25 > À : haproxy@formilux.org; w...@1wt.eu > Objet : Question on healtchecks > > I have an active-passive HAProxy setup using keepalived, similar to > this: > http://www.howtoforge.com/setting-up-a-high-availability-load-balancer- > with-haproxy-keepalived-on-debian-lenny > > My question is, is there any way to have the healtchecks performed on > only the active HAProxy? Currently both the active and passive HAProxys > ping my servers every 3 seconds at (almost) the same time. I have > enabled the spread-check option with a value of 5 but it seems to make > little difference. > > Is there anything I can do to remedy this problem? Thanks! Hi, With keepalived you have the option to run a script on certain events (transition from master to backup, from backup to master, ...). So why not just fire up haproxy on the backup machine when it becomes master ? Emmanuel
Re: "timeout client" weird behaviour in 1.3.22
On 13 Apr 2010, cy...@bouthors.org wrote: > I upgraded from 1.3.15 (lenny) to 1.3.22 (lenny-backports) and "timeout > client X" now seems to close connections at X even if client > continuously sends something. After a short chat on #haproxy with Hervé Commowick, I came to the conclusion that this bug is only reproducible when "option forceclose" is activated and "mode tcp" is used. "option forceclose" should not affect "mode tcp" behavior but it does. Here's a minimalist configuration that reproduces the bug: defaults timeout connect 10s timeout client 3s timeout server 15m option forceclose listen testssh 192.168.0.1:23 mode tcp server localhost 127.0.0.1:22 listen testssh 192.168.0.1:81 server localhost 127.0.0.1:80 If you connect on port 23, you get disconnected after 3 seconds, even if you keep on typing. I can reproduce the bug with 1.3.18, 1.3.22 and 1.3.24. The same configuration works as expected with 1.3.15, I mean you only get disconnected after 3 seconds of *inactivity*. Any idea what happened between 1.3.15 and 1.3.18? -- Cyril Bouthors
Re: Question on healtchecks
On Tue, Apr 13, 2010 at 06:47:04PM +0200, Emmanuel Bailleul wrote: > > -Message d'origine- > > De : Static Void [mailto:static.void@gmail.com] > > Envoyé : mardi 13 avril 2010 16:25 > > À : haproxy@formilux.org; w...@1wt.eu > > Objet : Question on healtchecks > > > > I have an active-passive HAProxy setup using keepalived, similar to > > this: > > http://www.howtoforge.com/setting-up-a-high-availability-load-balancer- > > with-haproxy-keepalived-on-debian-lenny > > > > My question is, is there any way to have the healtchecks performed on > > only the active HAProxy? Currently both the active and passive HAProxys > > ping my servers every 3 seconds at (almost) the same time. I have > > enabled the spread-check option with a value of 5 but it seems to make > > little difference. > > > > Is there anything I can do to remedy this problem? Thanks! > > Hi, > > With keepalived you have the option to run a script on certain events > (transition from master to backup, from backup to master, ...). So why not > just fire up haproxy on the backup machine when it becomes master ? Well, anyway in my opinion, the original question is wrong. It is important for the second LB to be aware of the servers' health because you want it to be immediately operational in case of a LB failure. You would not want to have it use wrong servers or take some time to discover which ones are OK and which ones aren't. Also, having an LB start only upon failover is really not practical at all, as it increases the failover time, and it can make it harder to debug issues. Imagine if your LBs are starting to flapping and the service is constantly started and stopped. It completely voids the initial point of putting them in high availability. Last, you're saying that both of your LBs send a check every 3 seconds, which means that your servers receive on average a check every 1.5 seconds. If this load is even minimally perceivable on the servers, then you don't need a load balancer, you need to rewrite the application, because you'll never have any visitor satisfied with the response time ! I'm aware of some people doing checks every 20 ms (50 checks per second per server and per LB) in order to speed up error detection in critical environments. The servers then receive 100 checks per second and barely notice them. I don't suggest going that low, it's just to illustrate that this cannot be a problem. In fact the only problem related to the check interval generally is the timeout because some in-depth tests may sometimes involve many components which sometimes require a bit more time to complete a test. It's trickier to adjust (using "timeout check") but still doable. But clearly 2 checks every 3 seconds have no reason to be any sort of a "problem". Regards, Willy
Re: "timeout client" weird behaviour in 1.3.22
Hi Cyril and Willy, Le mardi 13 avril 2010 19:10:14, Cyril Bouthors a écrit : > On 13 Apr 2010, cy...@bouthors.org wrote: > > > I upgraded from 1.3.15 (lenny) to 1.3.22 (lenny-backports) and "timeout > > client X" now seems to close connections at X even if client > > continuously sends something. > > After a short chat on #haproxy with Hervé Commowick, I came to the > conclusion that this bug is only reproducible when "option forceclose" > is activated and "mode tcp" is used. > > "option forceclose" should not affect "mode tcp" behavior but it does. > (...) > > I can reproduce the bug with 1.3.18, 1.3.22 and 1.3.24. > > The same configuration works as expected with 1.3.15, I mean you only > get disconnected after 3 seconds of *inactivity*. > > Any idea what happened between 1.3.15 and 1.3.18? This changes were introduced in 1.3.16 with this commit : http://haproxy.1wt.eu/git?p=haproxy-1.3.git;a=commit;h=55a8d0e1bb1507c7c80e812dff6e516e29f3c507 where a test on "PR_O_FORCE_CLO" was moved in session.c Maybe "option forceclose" should be automatically disabled in tcp mode, as it is done for "option httplog" and others since 1.3.23 (or maybe someone might also want it in tcp mode). -- Cyril Bonté
