Hi Willy Thanks for fast answer. In the meantime I tried to rollback to HAProxy version 2.7.9-1ppa1~jammy 2023/06/07 - https://haproxy.org/ Status: stable branch - will stop receiving fixes around Q1 2024. Known bugs: http://www.haproxy.org/bugs/bugs-2.7.9.html Running on: Linux 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64
And under 2.7.9-1 It works, but when I then switch back to: HAProxy version 2.8.1-1ppa1~jammy 2023/07/03 - https://haproxy.org/ Status: long-term supported branch - will stop receiving fixes around Q2 2028. Known bugs: http://www.haproxy.org/bugs/bugs-2.8.1.html Running on: Linux 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64 It stop working again. I will try you suggestion as it sound as a solution/ explanation, or at least what I was hoping to do in the first place. I will let you know if it fix the problem. Thanks again for fast response. Regards Henning -----Oprindelig meddelelse----- Fra: Willy Tarreau <w...@1wt.eu> Sendt: 29. juli 2023 23:34 Til: Henning Svane <h...@energy.dk> Cc: haproxy@formilux.org Emne: Re: Strange problem Hi Henning, On Sat, Jul 29, 2023 at 07:21:58PM +0000, Henning Svane wrote: > Hi > Today I started to get this problem. > Linie 29140: Jul 29 18:47:09 haproxyxmail01 haproxy[1010]: 192.168.y.65:26570 > [29/Jul/2023:18:47:09.605] FrontEnd_Xmail_L7_IPv4~ > FrontEnd_Xmail_L7_IPv4/<NOSRV> -1/-1/-1/-1/0 503 108 - - SC-- 10/10/0/0/0 0/0 > "HEAD https://mail.domin.com/OAB/857f4bf9-4f97-466c-a337-6316b1aa3cc8/oab.xml > HTTP/2.0<https://mail.domin.com/OAB/857f4bf9-4f97-466c-a337-6316b1aa3cc8/oab.xml%20HTTP/2.0>" > > If I understand the error correctly, it says that it do not find a match for > a backend or is this correct, and if so why, because there is a match?? Yes that's it. > "Mail.domain.com" is the correct FQDN just change here. The only > different is it ends on http/2.0 Where all the request that works is > http/1.1 which fits as Exchange do not support 2.0 but only 1.1 I think I have an explanation below: acl XMail_Autodiscover url_beg -i /autodiscover acl XMail_EAS url_beg -i /microsoft-server-activesync acl XMail_ECP url_beg -i /ecp acl XMail_EWS url_beg -i /ews acl XMail_MAPI url_beg -i /mapi acl XMail_OAB url_beg -i /oab acl XMail_OWA url_beg -i /owa acl XMail_RPC url_beg -i /rpc acl XMail_PowerShell url_beg -i /powershell acl XMail_NotAllowed url_beg -i / Your rules rely on url_beg which matches the full URL, not just the path component. HTTP/2 always sends full URLs, while this is optional in HTTP/1. If you want to match the path only, your ACLs ought to use "path_beg" instead of "url_beg". > But what make it strange is when I try to debug with Fiddler the > problem goes away, and all works, when I turn of Fiddler the problem starts > again. I don't know exactly how fiddler works but I suspect it works in reverse- proxy mode and just does not support HTTP/2, thus it forces the client to negotiate HTTP/1.1. Hoping this helps, Willy
