Re: Recommendations for deleting headers by regexp in 2.x?
Ricardo, Am 21.09.20 um 11:29 schrieb Ricardo Fraile: > One mail on this thread said Your MUA appears to not specify the 'references' or 'in-reply-to' headers that are required for proper threading. This makes it unnecessarily hard to find the thread. To prevent all the others from searching through their emails the mailing list thread in question is this one (from January 2020): https://www.mail-archive.com/haproxy@formilux.org/msg36060.html Message-ID: calgeukyhmvpqmcbp2hi-z2dvutgyhdrsn_esgadjcdic2t-...@mail.gmail.com Best regards Tim Düsterhus
Re: Recommendations for deleting headers by regexp in 2.x?
Hello, I'm testing this behaviour with 2.2.3-0e58a34 with the line "http-request del-header x- -m beg" but it reports an error: [ALERT] 264/110329 (5812) : parsing [/etc/haproxy//haproxy.cfg:91]: 'http-request del-header' expects either 'if' or 'unless' followed by a condition but found '-m'. One mail on this thread said "...we both agreed that it makes sense to implement it...", but the 2.2 documentation doesn't have any reference. Maybe it will be on a future release? Or maybe is there any other alternative to delete headers based on regex or a matching method? Thanks,
Re: Recommendations for deleting headers by regexp in 2.x?
Hello, +1 for this feature I have some rspidel and rspirep waiting to be migrated to 2.2 when this feature will be available. Thanks, El vie, 14-02-2020 a las 09:59 +0100, Willy Tarreau escribió: > Hi James, > > On Fri, Jan 31, 2020 at 12:44:24PM -0800, James Brown wrote: > > So how should we move this proposal forward? I'm glad to contribute > > more > > patches... > > Sorry for the very late response, we needed to discuss this with > Christopher then both got busy and then forgot :-/ > > So after discussion, we both agreed that it makes sense to implement > it > following the same model as the ACLs described below : > > > > A variant of this could be to use the same syntax as the options > > > we already > > > use on ACL matches, which are "-m reg", "-m beg", "-m end". But > > > these will > > > also need to be placed after to avoid the same ambiguity (since > > > "-m" is a > > > token hence a valid header name). That would give for example : > > > > > > http-request del-header server > > > http-request del-header x-private- -m beg > > > http-request del-header x-.*company -m reg > > > http-request del-header -tracea -m end > > However, do not feel pressured to implement all matching methods! The > currently known ones are described in section 7.1 of the doc, I think > that "str", "reg", "sub", "beg" and "end" are the only ones which > would > make sense over the long term. In practice we could have "str" being > the current one and "beg" being the one with the prefix as you need. > If later others need more modes we can implement them (unless you > want > to provide them all at once of course). > > Thanks for whatever you can do in this area and sorry again for > responding late! > > Willy >
Re: Recommendations for deleting headers by regexp in 2.x?
Hi James, On Fri, Jan 31, 2020 at 12:44:24PM -0800, James Brown wrote: > So how should we move this proposal forward? I'm glad to contribute more > patches... Sorry for the very late response, we needed to discuss this with Christopher then both got busy and then forgot :-/ So after discussion, we both agreed that it makes sense to implement it following the same model as the ACLs described below : > > A variant of this could be to use the same syntax as the options we already > > use on ACL matches, which are "-m reg", "-m beg", "-m end". But these will > > also need to be placed after to avoid the same ambiguity (since "-m" is a > > token hence a valid header name). That would give for example : > > > > http-request del-header server > > http-request del-header x-private- -m beg > > http-request del-header x-.*company -m reg > > http-request del-header -tracea -m end However, do not feel pressured to implement all matching methods! The currently known ones are described in section 7.1 of the doc, I think that "str", "reg", "sub", "beg" and "end" are the only ones which would make sense over the long term. In practice we could have "str" being the current one and "beg" being the one with the prefix as you need. If later others need more modes we can implement them (unless you want to provide them all at once of course). Thanks for whatever you can do in this area and sorry again for responding late! Willy
Re: Recommendations for deleting headers by regexp in 2.x?
So how should we move this proposal forward? I'm glad to contribute more patches... On Fri, Jan 24, 2020 at 2:15 AM Willy Tarreau wrote: > On Fri, Jan 24, 2020 at 10:26:34AM +0100, Christopher Faulet wrote: > > Le 24/01/2020 à 09:17, Willy Tarreau a écrit : > > > On Fri, Jan 24, 2020 at 08:28:33AM +0100, Christopher Faulet wrote: > > > > Le 23/01/2020 à 19:59, James Brown a écrit : > > > > > I spent a couple of minutes and made the attached (pretty bad) > patch to > > > > > add a del-header-by-prefix. > > > > > > > > > > > > > Just an idea. Instead of adding a new action, it could be cleaner to > extend > > > > the del-header action adding some keywords. Something like: > > > > > > > >http-request del-header begin-with > > > >http-request del-header end-with > > > >http-request del-header match > > > > > > > > It could be also extended to replace-header and replace-value > actions. > > > > > > I would also prefer to extend existing syntax, however it's problematic > > > to insert optional words *before* arguments. This will complicate the > > > parsing, and even config manipulation scripts. > > > > > > That's why I thought we could instead just append an extra optional > > > keyword appended after the name, eventhough it's less elegant. > > > > > > > From the configuration parsing point of view, it is more or less the same > > thing. You must test if the second argument is defined or not. And in > fact, > > moving it after the header name is not a "better" solution because there > is > > an optional condition too at the end. So this one will not be the last > one. > > No, it's more complicated this way because you have to check each and every > word to figure the syntax. Example: how do you mention that you want to > remove the header field matching regex "unless" ? You'd have to do this : > > http-request del-header match unless > > And it's ambiguous, as it can either mean : > >- delete header name "match" unless a condition which needs to be > parsed, > and once figured invalid, you can roll back ; >- delete header described by regex "unless" with no condition > > When you do it the other way around it's way easier, because the name > always being the first argument makes sure the second one is limited to > a small subset (match/prefix/if/unless for example): > > http-request del-header unless match > > A variant of this could be to use the same syntax as the options we already > use on ACL matches, which are "-m reg", "-m beg", "-m end". But these will > also need to be placed after to avoid the same ambiguity (since "-m" is a > token hence a valid header name). That would give for example : > > http-request del-header server > http-request del-header x-private- -m beg > http-request del-header x-.*company -m reg > http-request del-header -tracea -m end > > Willy > -- James Brown Engineer
Re: Recommendations for deleting headers by regexp in 2.x?
On Fri, Jan 24, 2020 at 10:26:34AM +0100, Christopher Faulet wrote: > Le 24/01/2020 à 09:17, Willy Tarreau a écrit : > > On Fri, Jan 24, 2020 at 08:28:33AM +0100, Christopher Faulet wrote: > > > Le 23/01/2020 à 19:59, James Brown a écrit : > > > > I spent a couple of minutes and made the attached (pretty bad) patch to > > > > add a del-header-by-prefix. > > > > > > > > > > Just an idea. Instead of adding a new action, it could be cleaner to > > > extend > > > the del-header action adding some keywords. Something like: > > > > > >http-request del-header begin-with > > >http-request del-header end-with > > >http-request del-header match > > > > > > It could be also extended to replace-header and replace-value actions. > > > > I would also prefer to extend existing syntax, however it's problematic > > to insert optional words *before* arguments. This will complicate the > > parsing, and even config manipulation scripts. > > > > That's why I thought we could instead just append an extra optional > > keyword appended after the name, eventhough it's less elegant. > > > > From the configuration parsing point of view, it is more or less the same > thing. You must test if the second argument is defined or not. And in fact, > moving it after the header name is not a "better" solution because there is > an optional condition too at the end. So this one will not be the last one. No, it's more complicated this way because you have to check each and every word to figure the syntax. Example: how do you mention that you want to remove the header field matching regex "unless" ? You'd have to do this : http-request del-header match unless And it's ambiguous, as it can either mean : - delete header name "match" unless a condition which needs to be parsed, and once figured invalid, you can roll back ; - delete header described by regex "unless" with no condition When you do it the other way around it's way easier, because the name always being the first argument makes sure the second one is limited to a small subset (match/prefix/if/unless for example): http-request del-header unless match A variant of this could be to use the same syntax as the options we already use on ACL matches, which are "-m reg", "-m beg", "-m end". But these will also need to be placed after to avoid the same ambiguity (since "-m" is a token hence a valid header name). That would give for example : http-request del-header server http-request del-header x-private- -m beg http-request del-header x-.*company -m reg http-request del-header -tracea -m end Willy
Re: Recommendations for deleting headers by regexp in 2.x?
Le 24/01/2020 à 09:17, Willy Tarreau a écrit : On Fri, Jan 24, 2020 at 08:28:33AM +0100, Christopher Faulet wrote: Le 23/01/2020 à 19:59, James Brown a écrit : I spent a couple of minutes and made the attached (pretty bad) patch to add a del-header-by-prefix. Just an idea. Instead of adding a new action, it could be cleaner to extend the del-header action adding some keywords. Something like: http-request del-header begin-with http-request del-header end-with http-request del-header match It could be also extended to replace-header and replace-value actions. I would also prefer to extend existing syntax, however it's problematic to insert optional words *before* arguments. This will complicate the parsing, and even config manipulation scripts. That's why I thought we could instead just append an extra optional keyword appended after the name, eventhough it's less elegant. From the configuration parsing point of view, it is more or less the same thing. You must test if the second argument is defined or not. And in fact, moving it after the header name is not a "better" solution because there is an optional condition too at the end. So this one will not be the last one. For a configuration script, I hope this is easily manageable. Otherwise, I don't know how it could expect to handle all the complexity of the HAProxy configuration. -- Christopher Faulet
Re: Recommendations for deleting headers by regexp in 2.x?
On Fri, Jan 24, 2020 at 08:28:33AM +0100, Christopher Faulet wrote: > Le 23/01/2020 à 19:59, James Brown a écrit : > > I spent a couple of minutes and made the attached (pretty bad) patch to > > add a del-header-by-prefix. > > > > Just an idea. Instead of adding a new action, it could be cleaner to extend > the del-header action adding some keywords. Something like: > > http-request del-header begin-with > http-request del-header end-with > http-request del-header match > > It could be also extended to replace-header and replace-value actions. I would also prefer to extend existing syntax, however it's problematic to insert optional words *before* arguments. This will complicate the parsing, and even config manipulation scripts. That's why I thought we could instead just append an extra optional keyword appended after the name, eventhough it's less elegant. Willy
Re: Recommendations for deleting headers by regexp in 2.x?
+1 Jan 24, 2020 8:28:33 AM Christopher Faulet : > Le 23/01/2020 à 19:59, James Brown a écrit : > > > I spent a couple of minutes and made the attached (pretty bad) patch to add > > a > > del-header-by-prefix. > > > > > > Just an idea. Instead of adding a new action, it could be cleaner to extend > the > del-header action adding some keywords. Something like: > > http-request del-header begin-with > http-request del-header end-with > http-request del-header match > > It could be also extended to replace-header and replace-value actions. > > Just my 2 cents, > -- > Christopher Faulet >
Re: Recommendations for deleting headers by regexp in 2.x?
Le 23/01/2020 à 19:59, James Brown a écrit : I spent a couple of minutes and made the attached (pretty bad) patch to add a del-header-by-prefix. Just an idea. Instead of adding a new action, it could be cleaner to extend the del-header action adding some keywords. Something like: http-request del-header begin-with http-request del-header end-with http-request del-header match It could be also extended to replace-header and replace-value actions. Just my 2 cents, -- Christopher Faulet
Re: Recommendations for deleting headers by regexp in 2.x?
Willy, Am 23.01.20 um 21:40 schrieb Willy Tarreau: > On Thu, Jan 23, 2020 at 12:05:55PM -0800, James Brown wrote: >> Glad to do any other debugging you'd like. Just running `make >> TARGET=linux-glibc USE_NS=` or `make TARGET=osx`; nothing fancy. > > Ah now I have it. I think that it happens when we skip the code > paths that get ifdef'd out when openssl is not built in. We'll > have a look tomorrow now, thanks to you and Tim for the info! > Travis seems to confirm this. Only the build without SSL fails. And it fails all tests. https://github.com/haproxy/haproxy/runs/405627155 Best regards Tim Düsterhus
Re: Recommendations for deleting headers by regexp in 2.x?
On Thu, Jan 23, 2020 at 12:05:55PM -0800, James Brown wrote: > Glad to do any other debugging you'd like. Just running `make > TARGET=linux-glibc USE_NS=` or `make TARGET=osx`; nothing fancy. Ah now I have it. I think that it happens when we skip the code paths that get ifdef'd out when openssl is not built in. We'll have a look tomorrow now, thanks to you and Tim for the info! Willy
Re: Recommendations for deleting headers by regexp in 2.x?
Oh, and the crash is introduced in
8af03b396a6025437b675f9ecaa5db321ec4918c;
56dd354b3c55876c4e693fe5eee919e85b2bad53 is the last version that doesn't
crash for me.
On Thu, Jan 23, 2020 at 12:06 PM Tim Düsterhus wrote:
> Willy,
> James,
>
> Am 23.01.20 um 21:00 schrieb Willy Tarreau:
> > I'm impressed, I'm unable to reproduce it!
>
> FWIW, I can reproduce it:
>
> > [timwolla@/s/haproxy ((f22758d1…))]./haproxy -vv
> > HA-Proxy version 2.2-dev1-f22758-30 2020/01/23 - https://haproxy.org/
> > Status: development branch - not safe for use in production.
> > Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
> > Build options :
> > TARGET = linux-glibc
> > CPU = generic
> > CC = gcc
> > CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
> -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
> -Wno-missing-field-initializers -Wtype-limits
> > OPTIONS =
> >
> > Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE
> -PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
> -REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE
> +LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO -OPENSSL -LUA +FUTEX +ACCEPT4
> -MY_ACCEPT4 -ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS
> -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
> >
> > Default settings :
> > bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> >
> > Built with multi-threading support (MAX_THREADS=64, default=4).
> > Built with network namespace support.
> > Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> > Built without PCRE or PCRE2 support (using libc's regex instead)
> > Encrypted password support via crypt(3): yes
> > Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
> > Compression algorithms supported : identity("identity")
> >
> > Available polling systems :
> > epoll : pref=300, test result OK
> >poll : pref=200, test result OK
> > select : pref=150, test result OK
> > Total: 3 (3 usable), will use epoll.
> >
> > Available multiplexer protocols :
> > (protocols marked as cannot be specified using 'proto' keyword)
> > h2 : mode=HTTP side=FE|BE mux=H2
> > fcgi : mode=HTTP side=BEmux=FCGI
> > : mode=HTTP side=FE|BE mux=H1
> > : mode=TCPside=FE|BE mux=PASS
> >
> > Available services : none
> >
> > Available filters :
> > [SPOE] spoe
> > [CACHE] cache
> > [FCGI] fcgi-app
> > [TRACE] trace
> > [COMP] compression
> >
> > [timwolla@/s/haproxy ((f22758d1…))]./haproxy -d -f ./crasher.cfg
> > Available polling systems :
> > epoll : pref=300, test result OK
> >poll : pref=200, test result OK
> > select : pref=150, test result FAILED
> > Total: 3 (2 usable), will use epoll.
> >
> > Available filters :
> > [SPOE] spoe
> > [CACHE] cache
> > [FCGI] fcgi-app
> > [TRACE] trace
> > [COMP] compression
> > Using epoll() as the polling mechanism.
> > :test_fe.accept(0004)=0011 from [:::127.0.0.1:48030]
> ALPN=
> > :test_fe.clireq[0011:]: GET / HTTP/1.1
> > :test_fe.clihdr[0011:]: host: localhost:
> > :test_fe.clihdr[0011:]: user-agent: curl/7.47.0
> > :test_fe.clihdr[0011:]: accept: */*
> > 0001:test_fe.accept(0004)=0011 from [:::127.0.0.1:48030]
> ALPN=
> > 0001:test_fe.clicls[0010:]
> > 0001:test_fe.closed[0010:]
> > fish: “./haproxy -d -f ./crasher.cfg” terminated by signal SIGSEGV
> (Address boundary error)
>
> And in another Terminal:
>
> > $ curl localhost:
> > curl: (52) Empty reply from server
>
> With valgrind:
>
> > ==19765== Memcheck, a memory error detector
> > ==19765== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> > ==19765== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright
> info
> > ==19765== Command: ./haproxy -d -f ./crasher.cfg
> > ==19765==
> > Available polling systems :
> > epoll : pref=300, test result OK
> >poll : pref=200, test result OK
> > select : pref=150, test result FAILED
> > Total: 3 (2 usable), will use epoll.
> >
> > Available filters :
> > [SPOE] spoe
> > [CACHE] cache
> > [FCGI] fcgi-app
> > [TRACE] trace
> > [COMP] compression
> > Using epoll() as the polling mechanism.
> > [WARNING] 022/210543 (19765) : [./haproxy.main()] Cannot raise FD limit
> to 2071, limit is 1024. This will fail in >= v2.3
> > [ALERT] 022/210543 (19765) : [./haproxy.main()] FD limit (1024) too low
> for maxconn=1024/maxsock=2071. Please raise 'ulimit-n' to 2071 or more to
> avoid any trouble.This will fail in >= v2.3
> > ==19765== Thread 2:
> > ==19765== Syscall param
Re: Recommendations for deleting headers by regexp in 2.x?
Willy,
James,
Am 23.01.20 um 21:00 schrieb Willy Tarreau:
> I'm impressed, I'm unable to reproduce it!
FWIW, I can reproduce it:
> [timwolla@/s/haproxy ((f22758d1…))]./haproxy -vv
> HA-Proxy version 2.2-dev1-f22758-30 2020/01/23 - https://haproxy.org/
> Status: development branch - not safe for use in production.
> Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
> Build options :
> TARGET = linux-glibc
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
> -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
> -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
> -Wno-missing-field-initializers -Wtype-limits
> OPTIONS =
>
> Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT
> -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM
> -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT
> +CRYPT_H -VSYSCALL +GETADDRINFO -OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4
> -ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL
> -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
>
> Default settings :
> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with multi-threading support (MAX_THREADS=64, default=4).
> Built with network namespace support.
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
> IP_FREEBIND
> Built without PCRE or PCRE2 support (using libc's regex instead)
> Encrypted password support via crypt(3): yes
> Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
> Compression algorithms supported : identity("identity")
>
> Available polling systems :
> epoll : pref=300, test result OK
>poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available multiplexer protocols :
> (protocols marked as cannot be specified using 'proto' keyword)
> h2 : mode=HTTP side=FE|BE mux=H2
> fcgi : mode=HTTP side=BEmux=FCGI
> : mode=HTTP side=FE|BE mux=H1
> : mode=TCPside=FE|BE mux=PASS
>
> Available services : none
>
> Available filters :
> [SPOE] spoe
> [CACHE] cache
> [FCGI] fcgi-app
> [TRACE] trace
> [COMP] compression
>
> [timwolla@/s/haproxy ((f22758d1…))]./haproxy -d -f ./crasher.cfg
> Available polling systems :
> epoll : pref=300, test result OK
>poll : pref=200, test result OK
> select : pref=150, test result FAILED
> Total: 3 (2 usable), will use epoll.
>
> Available filters :
> [SPOE] spoe
> [CACHE] cache
> [FCGI] fcgi-app
> [TRACE] trace
> [COMP] compression
> Using epoll() as the polling mechanism.
> :test_fe.accept(0004)=0011 from [:::127.0.0.1:48030] ALPN=
> :test_fe.clireq[0011:]: GET / HTTP/1.1
> :test_fe.clihdr[0011:]: host: localhost:
> :test_fe.clihdr[0011:]: user-agent: curl/7.47.0
> :test_fe.clihdr[0011:]: accept: */*
> 0001:test_fe.accept(0004)=0011 from [:::127.0.0.1:48030] ALPN=
> 0001:test_fe.clicls[0010:]
> 0001:test_fe.closed[0010:]
> fish: “./haproxy -d -f ./crasher.cfg” terminated by signal SIGSEGV (Address
> boundary error)
And in another Terminal:
> $ curl localhost:
> curl: (52) Empty reply from server
With valgrind:
> ==19765== Memcheck, a memory error detector
> ==19765== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==19765== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==19765== Command: ./haproxy -d -f ./crasher.cfg
> ==19765==
> Available polling systems :
> epoll : pref=300, test result OK
>poll : pref=200, test result OK
> select : pref=150, test result FAILED
> Total: 3 (2 usable), will use epoll.
>
> Available filters :
> [SPOE] spoe
> [CACHE] cache
> [FCGI] fcgi-app
> [TRACE] trace
> [COMP] compression
> Using epoll() as the polling mechanism.
> [WARNING] 022/210543 (19765) : [./haproxy.main()] Cannot raise FD limit to
> 2071, limit is 1024. This will fail in >= v2.3
> [ALERT] 022/210543 (19765) : [./haproxy.main()] FD limit (1024) too low for
> maxconn=1024/maxsock=2071. Please raise 'ulimit-n' to 2071 or more to avoid
> any trouble.This will fail in >= v2.3
> ==19765== Thread 2:
> ==19765== Syscall param timer_create(evp.sigev_value) points to uninitialised
> byte(s)
> ==19765==at 0x5292FE0: timer_create@@GLIBC_2.3.3 (timer_create.c:78)
> ==19765==by 0x53824D: init_wdt_per_thread (wdt.c:146)
> ==19765==by 0x4B1D84: run_thread_poll_loop (haproxy.c:2723)
> ==19765==by 0x50796B9: start_thread (pthread_create.c:333)
> ==19765==by 0x559E41C: clone (clone.S:109)
> ==19765== Address 0x643ea64 is on thread 2's
Re: Recommendations for deleting headers by regexp in 2.x?
Glad to do any other debugging you'd like. Just running `make
TARGET=linux-glibc USE_NS=` or `make TARGET=osx`; nothing fancy.
On Thu, Jan 23, 2020 at 12:00 PM Willy Tarreau wrote:
> On Thu, Jan 23, 2020 at 11:54:17AM -0800, James Brown wrote:
> > Where master == f22758d12af5e9f3919f24bf913b883a62df7d93, the following
> > config fails on both linux-glibc and osx:
> >
> > global
> > maxconn 1024
> >
> > defaults
> > timeout client 9s
> > timeout server 9s
> > timeout connect 1s
> >
> > frontend test_fe
> > mode http
> > bind :::
> > use_backend test_be
> >
> > backend test_be
> > mode http
> > server localhost 127.0.0.1:1
> >
> > Every request crashes immediately before connecting to the backend.
>
> I'm impressed, I'm unable to reproduce it!
>
> $ telnet 0
> Trying 0.0.0.0...
> Connected to 0.
> Escape character is '^]'.
> GET / HTTP/1.1
>
> HTTP/1.1 200 OK
> connection: close
>
> > Backtrace:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > back_handle_st_con (s=0x94abd0) at src/backend.c:1937
> > 1937 if (!conn->mux && !(conn->flags & CO_FL_WAIT_XPRT)) {
> > (gdb) bt
> > #0 back_handle_st_con (s=0x94abd0) at src/backend.c:1937
> > #1 0x0042ae75 in process_stream (t=0x94b020, context=0x94abd0,
> > state=) at src/stream.c:1662
> > #2 0x005083c2 in process_runnable_tasks () at src/task.c:461
> > #3 0x004bb36b in run_poll_loop (data=) at
> > src/haproxy.c:2630
> > #4 run_thread_poll_loop (data=) at
> src/haproxy.c:2783
> > #5 0x004bdba5 in main (argc=, argv= > optimized out>) at src/haproxy.c:3483
> >
> > Segfault is on the same line on OS X and Linux.
>
> I'm pretty sure the connection is null (or almost null as derived from
> the CS) though that should not happen at this place. I'll have another
> look at this one tomorrow. Additionally this "if" block will be entirely
> removed :-) But I really want to understand how we manage to enter there
> with an invalid connection.
>
> Thank you!
> Willy
>
--
James Brown
Engineer
Re: Recommendations for deleting headers by regexp in 2.x?
On Thu, Jan 23, 2020 at 11:54:17AM -0800, James Brown wrote:
> Where master == f22758d12af5e9f3919f24bf913b883a62df7d93, the following
> config fails on both linux-glibc and osx:
>
> global
> maxconn 1024
>
> defaults
> timeout client 9s
> timeout server 9s
> timeout connect 1s
>
> frontend test_fe
> mode http
> bind :::
> use_backend test_be
>
> backend test_be
> mode http
> server localhost 127.0.0.1:1
>
> Every request crashes immediately before connecting to the backend.
I'm impressed, I'm unable to reproduce it!
$ telnet 0
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 200 OK
connection: close
> Backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> back_handle_st_con (s=0x94abd0) at src/backend.c:1937
> 1937 if (!conn->mux && !(conn->flags & CO_FL_WAIT_XPRT)) {
> (gdb) bt
> #0 back_handle_st_con (s=0x94abd0) at src/backend.c:1937
> #1 0x0042ae75 in process_stream (t=0x94b020, context=0x94abd0,
> state=) at src/stream.c:1662
> #2 0x005083c2 in process_runnable_tasks () at src/task.c:461
> #3 0x004bb36b in run_poll_loop (data=) at
> src/haproxy.c:2630
> #4 run_thread_poll_loop (data=) at src/haproxy.c:2783
> #5 0x004bdba5 in main (argc=, argv= optimized out>) at src/haproxy.c:3483
>
> Segfault is on the same line on OS X and Linux.
I'm pretty sure the connection is null (or almost null as derived from
the CS) though that should not happen at this place. I'll have another
look at this one tomorrow. Additionally this "if" block will be entirely
removed :-) But I really want to understand how we manage to enter there
with an invalid connection.
Thank you!
Willy
Re: Recommendations for deleting headers by regexp in 2.x?
Where master == f22758d12af5e9f3919f24bf913b883a62df7d93, the following
config fails on both linux-glibc and osx:
global
maxconn 1024
defaults
timeout client 9s
timeout server 9s
timeout connect 1s
frontend test_fe
mode http
bind :::
use_backend test_be
backend test_be
mode http
server localhost 127.0.0.1:1
Every request crashes immediately before connecting to the backend.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
back_handle_st_con (s=0x94abd0) at src/backend.c:1937
1937 if (!conn->mux && !(conn->flags & CO_FL_WAIT_XPRT)) {
(gdb) bt
#0 back_handle_st_con (s=0x94abd0) at src/backend.c:1937
#1 0x0042ae75 in process_stream (t=0x94b020, context=0x94abd0,
state=) at src/stream.c:1662
#2 0x005083c2 in process_runnable_tasks () at src/task.c:461
#3 0x004bb36b in run_poll_loop (data=) at
src/haproxy.c:2630
#4 run_thread_poll_loop (data=) at src/haproxy.c:2783
#5 0x004bdba5 in main (argc=, argv=) at src/haproxy.c:3483
Segfault is on the same line on OS X and Linux.
On Thu, Jan 23, 2020 at 11:49 AM Willy Tarreau wrote:
> On Thu, Jan 23, 2020 at 11:05:57AM -0800, James Brown wrote:
> > Update: I rebased back to the last non-segfaulting commit and this
> patch's
> > functionality appears to work in very limited testing.
>
> Cool, thanks for doing it. I've quickly read it and I'm also convinced it
> must work. I'll take more time tomorrow doing a more in-depth review and
> suggesting some parts to split into different patches.
>
> I'm also interested in knowing more about this segfault in master, because
> for me all reg-tests were OK before I pushed last update, thus if you have
> a reproducer I'm very interested :-)
>
> Thanks,
> Willy
>
--
James Brown
Engineer
Re: Recommendations for deleting headers by regexp in 2.x?
On Thu, Jan 23, 2020 at 11:05:57AM -0800, James Brown wrote: > Update: I rebased back to the last non-segfaulting commit and this patch's > functionality appears to work in very limited testing. Cool, thanks for doing it. I've quickly read it and I'm also convinced it must work. I'll take more time tomorrow doing a more in-depth review and suggesting some parts to split into different patches. I'm also interested in knowing more about this segfault in master, because for me all reg-tests were OK before I pushed last update, thus if you have a reproducer I'm very interested :-) Thanks, Willy
Re: Recommendations for deleting headers by regexp in 2.x?
Update: I rebased back to the last non-segfaulting commit and this patch's functionality appears to work in very limited testing. On Thu, Jan 23, 2020 at 10:59 AM James Brown wrote: > I spent a couple of minutes and made the attached (pretty bad) patch to > add a del-header-by-prefix. > > Unfortunately, I made it off of master before noticing that master > segfaults on every request, so I haven't tested it yet. At least it > compiles... Feel free to use it, throw it away, or whatever else suits your > fancy. > > > > On Thu, Jan 23, 2020 at 9:26 AM James Brown wrote: > >> Yes, they’re all identified by a prefix. >> >> On Thu, Jan 23, 2020 at 02:03 Willy Tarreau wrote: >> >>> Hi James, >>> >>> On Wed, Jan 22, 2020 at 04:19:41PM -0800, James Brown wrote: >>> > We're upgrading from 1.8 to 2.x and one of the things I've noticed is >>> that >>> > reqidel and rspidel seem to be totally gone in 2.1... What's the new >>> > recommendation to delete headers from request/response based on a >>> regular >>> > expression? Do I have to write a Lua action to do this now? I read >>> through >>> > the documentation for http-request and http-response and there doesn't >>> seem >>> > to be an `http-request del-header-by-regex`... >>> > >>> > Our use case is that we have dozens of different internal headers >>> behind a >>> > prefix, and we promise that we'll strip them all for incoming requests >>> and >>> > outgoing responses at the edge load balancer. That is harder to do if >>> we >>> > can't delete all headers matching a certain regex... >>> >>> That's an intereting use case, which I find totally legitimate and that >>> we need to figure how to address. In 2.0 you can still rely on rspdel >>> but we then need to have a solution for 2.2. Probably that in the short >>> term using Lua will be the easiest solution. And maybe we'd need to add >>> a new action such as "del-headers" which would take a regex or a prefix. >>> By the way, are all your headers identified by the same prefix ? I'm >>> asking because if that's the case, maybe we could append an optional >>> argument to del-header to mention that we want to delete all those >>> starting with this prefix and not just this exact one. >>> >>> Willy >>> >> -- >> James Brown >> Engineer >> > > > -- > James Brown > Engineer > -- James Brown Engineer
Re: Recommendations for deleting headers by regexp in 2.x?
I spent a couple of minutes and made the attached (pretty bad) patch to add a del-header-by-prefix. Unfortunately, I made it off of master before noticing that master segfaults on every request, so I haven't tested it yet. At least it compiles... Feel free to use it, throw it away, or whatever else suits your fancy. On Thu, Jan 23, 2020 at 9:26 AM James Brown wrote: > Yes, they’re all identified by a prefix. > > On Thu, Jan 23, 2020 at 02:03 Willy Tarreau wrote: > >> Hi James, >> >> On Wed, Jan 22, 2020 at 04:19:41PM -0800, James Brown wrote: >> > We're upgrading from 1.8 to 2.x and one of the things I've noticed is >> that >> > reqidel and rspidel seem to be totally gone in 2.1... What's the new >> > recommendation to delete headers from request/response based on a >> regular >> > expression? Do I have to write a Lua action to do this now? I read >> through >> > the documentation for http-request and http-response and there doesn't >> seem >> > to be an `http-request del-header-by-regex`... >> > >> > Our use case is that we have dozens of different internal headers >> behind a >> > prefix, and we promise that we'll strip them all for incoming requests >> and >> > outgoing responses at the edge load balancer. That is harder to do if we >> > can't delete all headers matching a certain regex... >> >> That's an intereting use case, which I find totally legitimate and that >> we need to figure how to address. In 2.0 you can still rely on rspdel >> but we then need to have a solution for 2.2. Probably that in the short >> term using Lua will be the easiest solution. And maybe we'd need to add >> a new action such as "del-headers" which would take a regex or a prefix. >> By the way, are all your headers identified by the same prefix ? I'm >> asking because if that's the case, maybe we could append an optional >> argument to del-header to mention that we want to delete all those >> starting with this prefix and not just this exact one. >> >> Willy >> > -- > James Brown > Engineer > -- James Brown Engineer 0001-add-http-request-del-header-prefix-and-http-response.patch Description: Binary data
Re: Recommendations for deleting headers by regexp in 2.x?
Yes, they’re all identified by a prefix. On Thu, Jan 23, 2020 at 02:03 Willy Tarreau wrote: > Hi James, > > On Wed, Jan 22, 2020 at 04:19:41PM -0800, James Brown wrote: > > We're upgrading from 1.8 to 2.x and one of the things I've noticed is > that > > reqidel and rspidel seem to be totally gone in 2.1... What's the new > > recommendation to delete headers from request/response based on a regular > > expression? Do I have to write a Lua action to do this now? I read > through > > the documentation for http-request and http-response and there doesn't > seem > > to be an `http-request del-header-by-regex`... > > > > Our use case is that we have dozens of different internal headers behind > a > > prefix, and we promise that we'll strip them all for incoming requests > and > > outgoing responses at the edge load balancer. That is harder to do if we > > can't delete all headers matching a certain regex... > > That's an intereting use case, which I find totally legitimate and that > we need to figure how to address. In 2.0 you can still rely on rspdel > but we then need to have a solution for 2.2. Probably that in the short > term using Lua will be the easiest solution. And maybe we'd need to add > a new action such as "del-headers" which would take a regex or a prefix. > By the way, are all your headers identified by the same prefix ? I'm > asking because if that's the case, maybe we could append an optional > argument to del-header to mention that we want to delete all those > starting with this prefix and not just this exact one. > > Willy > -- James Brown Engineer
Re: Recommendations for deleting headers by regexp in 2.x?
Hi James, On Wed, Jan 22, 2020 at 04:19:41PM -0800, James Brown wrote: > We're upgrading from 1.8 to 2.x and one of the things I've noticed is that > reqidel and rspidel seem to be totally gone in 2.1... What's the new > recommendation to delete headers from request/response based on a regular > expression? Do I have to write a Lua action to do this now? I read through > the documentation for http-request and http-response and there doesn't seem > to be an `http-request del-header-by-regex`... > > Our use case is that we have dozens of different internal headers behind a > prefix, and we promise that we'll strip them all for incoming requests and > outgoing responses at the edge load balancer. That is harder to do if we > can't delete all headers matching a certain regex... That's an intereting use case, which I find totally legitimate and that we need to figure how to address. In 2.0 you can still rely on rspdel but we then need to have a solution for 2.2. Probably that in the short term using Lua will be the easiest solution. And maybe we'd need to add a new action such as "del-headers" which would take a regex or a prefix. By the way, are all your headers identified by the same prefix ? I'm asking because if that's the case, maybe we could append an optional argument to del-header to mention that we want to delete all those starting with this prefix and not just this exact one. Willy
Recommendations for deleting headers by regexp in 2.x?
We're upgrading from 1.8 to 2.x and one of the things I've noticed is that reqidel and rspidel seem to be totally gone in 2.1... What's the new recommendation to delete headers from request/response based on a regular expression? Do I have to write a Lua action to do this now? I read through the documentation for http-request and http-response and there doesn't seem to be an `http-request del-header-by-regex`... Our use case is that we have dozens of different internal headers behind a prefix, and we promise that we'll strip them all for incoming requests and outgoing responses at the edge load balancer. That is harder to do if we can't delete all headers matching a certain regex... -- James Brown Engineer
Re: Regexp
On 07/20/2018 12:03 AM, Aleksandar Lazic wrote:
Hi.
On 18/07/2018 13:10, Haim Ari wrote:
Hello,
Trying to set backend by regexp
This regexp works outside of haproxy
String:
/1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789
Regexp:
^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789
What is the right syntax for this in haproxy ?
I would use
https://regex101.com/r/TjH7Ul/1/
^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789
AFAIK, even if this is correct, you do not have to escape the '/'
characters to match them. You had to do that in your GUI because you
selected a regex form with '/' as delimiter character (/.../gm).
haproxy uses POSIX regexes with ^.[$()|*+?{\ as list of characters which
must be escaped if you want them to be interpreted as literal characters
(see regex(7)).
There is an explanation in your GUI which indicates exactly that:
"\/ matches the character / literally (case sensitive)"
So, the regex above may be shortened as follows:
^/1\.0/manage/bu/ca\?token=(.*).segId=(.*).partner=123456789
which is a bit more readable.
Fred.
Re: Regexp
ok found it,
It should be url_reg not path_reg
It works now
Haim Ari / SysOps Manager
M: 972.584563032 / T: 972.722288367
From: Haim Ari
Sent: Sunday, July 22, 2018 2:51:41 PM
To: Aleksandar Lazic
Cc: haproxy@formilux.org
Subject: Re: Regexp
And the config is:
frontend HTTP-In
option http-buffer-request
bind-process 1 2
acl publisher-x path_reg
^\/1\.0\/manage\/bu\/ca\?token=.*seg=.*partner=987654321.*
use_backend web1 if publisher-x
bind 217.65.36.201:80
bind 217.65.36.202:80
bind 217.65.36.203:80
bind 217.65.36.204:80
maxconn 1
timeout client-fin 10s
default_backend in
-
backend web1
fullconn 2000
timeout queue 1s
option httpchk GET /keepalive_check
balanceroundrobin
option abortonclose
option forwardfor
timeout server 10s
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server web-1 192.168.192.168:8990 weight 100 check inter 10s minconn 10
maxconn 200 maxqueue 1 slowstart 120s
Haim Ari / SysOps Manager
M: 972.584563032 / T: 972.722288367
From: Haim Ari
Sent: Sunday, July 22, 2018 2:44:11 PM
To: Aleksandar Lazic
Cc: haproxy@formilux.org
Subject: Re: Regexp
Version:
HA-Proxy version 1.8.1-1ppa1~xenial 2017/12/04
Use case:
Need to direct these path_reg to a none default backend
req:
/1.0/manage/bu/ca?token=68b6f68b6f68b6f68b6f=123456789=987654321=1=CP=AF%2CAX%2CAL%2CDZ%2CAS%2CAD%2CAO%2CAI%2CAQ%2CAG%2CAR%2CAM%2CAW%2CAU%2CAT%2CAZ%2CBS%2CBH%2CBD%2CBB%2CBY%2CBE%2CBZ%2CBJ%2CBM%2CBT%2CBO%2CBA%2CBW%2CBV%2CBR%2CIO%2CBN%2CBG%2CBF%2CBI%2CKH%2CCM%2CCA%2CCV%2CKY%2CCF%2CTD%2CCL%2CCN%2CCX%2CCC%2CCO%2CKM%2CCG%2CCD%2CCK%2CCR%2CCI%2CHR%2CCU%2CCY%2CCZ%2CDK%2CDJ%2CDM%2CDO%2CEC%2CEG%2CSV%2CGQ%2CER%2CEE%2CET%2CFK%2CFO%2CFJ%2CFI%2CFR%2CGF%2CPF%2CTF%2CGA%2CGM%2CGE%2CDE%2CGH%2CGI%2CGR%2CGL%2CGD%2CGP%2CGU%2CGT%2CGG%2CGN%2CGW%2CGY%2CHT%2CHM%2CVA%2CHN%2CHK%2CHU%2CIS%2CIN%2CID%2CIR%2CIQ%2CIE%2CIM%2CIL%2CIT%2CJM%2CJP%2CJE%2CJO%2CKZ%2CKE%2CKI%2CKP%2CKR%2CKW%2CKG%2CLA%2CLV%2CLB%2CLS%2CLR%2CLY%2CLI%2CLT%2CLU%2CMO%2CMK%2CMG%2CMW%2CMY%2CMV%2CML%2CMT%2CMH%2CMQ%2CMR%2CMU%2CYT%2CMX%2CFM%2CMD%2CMC%2CMN%2CMS%2CMA%2CMZ%2CMM%2CNA%2CNR%2CNP%2CNL%2CAN%2CNC%2CNZ%2CNI%2CNE%2CNG%2CNU%2CNF%2CMP%2CNO%2COM%2CPK%2CPW%2CPS%2CPA%2CPG%2CPY%2CPE%2CPH%2CPN%2CPL%2CPT%2CPR%2CQA%2CRE%
The regexp i tried and works externally :
^\/1\.0\/manage\/bu\/ca\?token=.*seg=.*partner=98765432.*
Thank you
Haim Ari / SysOps Manager
M: 972.584563032 / T: 972.722288367
From: Aleksandar Lazic
Sent: Friday, July 20, 2018 1:03 AM
To: Haim Ari
Cc: haproxy@formilux.org
Subject: Re: Regexp
Hi.
On 18/07/2018 13:10, Haim Ari wrote:
>Hello,
>
>Trying to set backend by regexp
>
>This regexp works outside of haproxy
>
>String:
>
>/1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789
>
>Regexp:
>
>^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789
>
>What is the right syntax for this in haproxy ?
I would use
https://regex101.com/r/TjH7Ul/1/
^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789
and backref \1 \2
But that's just a wild guess as the information's from you are very small.
Which version of haproxy (haproxy -vv)?
Which use case do you have?
http-request/http-response/acl/..?
Some config snipped would also help a little bit ;-).
>Thank you
Best regards
Aleks
Re: Regexp
And the config is:
frontend HTTP-In
option http-buffer-request
bind-process 1 2
acl publisher-x path_reg
^\/1\.0\/manage\/bu\/ca\?token=.*seg=.*partner=987654321.*
use_backend web1 if publisher-x
bind 217.65.36.201:80
bind 217.65.36.202:80
bind 217.65.36.203:80
bind 217.65.36.204:80
maxconn 1
timeout client-fin 10s
default_backend in
-
backend web1
fullconn 2000
timeout queue 1s
option httpchk GET /keepalive_check
balanceroundrobin
option abortonclose
option forwardfor
timeout server 10s
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server web-1 192.168.192.168:8990 weight 100 check inter 10s minconn 10
maxconn 200 maxqueue 1 slowstart 120s
Haim Ari / SysOps Manager
M: 972.584563032 / T: 972.722288367
From: Haim Ari
Sent: Sunday, July 22, 2018 2:44:11 PM
To: Aleksandar Lazic
Cc: haproxy@formilux.org
Subject: Re: Regexp
Version:
HA-Proxy version 1.8.1-1ppa1~xenial 2017/12/04
Use case:
Need to direct these path_reg to a none default backend
req:
/1.0/manage/bu/ca?token=68b6f68b6f68b6f68b6f=123456789=987654321=1=CP=AF%2CAX%2CAL%2CDZ%2CAS%2CAD%2CAO%2CAI%2CAQ%2CAG%2CAR%2CAM%2CAW%2CAU%2CAT%2CAZ%2CBS%2CBH%2CBD%2CBB%2CBY%2CBE%2CBZ%2CBJ%2CBM%2CBT%2CBO%2CBA%2CBW%2CBV%2CBR%2CIO%2CBN%2CBG%2CBF%2CBI%2CKH%2CCM%2CCA%2CCV%2CKY%2CCF%2CTD%2CCL%2CCN%2CCX%2CCC%2CCO%2CKM%2CCG%2CCD%2CCK%2CCR%2CCI%2CHR%2CCU%2CCY%2CCZ%2CDK%2CDJ%2CDM%2CDO%2CEC%2CEG%2CSV%2CGQ%2CER%2CEE%2CET%2CFK%2CFO%2CFJ%2CFI%2CFR%2CGF%2CPF%2CTF%2CGA%2CGM%2CGE%2CDE%2CGH%2CGI%2CGR%2CGL%2CGD%2CGP%2CGU%2CGT%2CGG%2CGN%2CGW%2CGY%2CHT%2CHM%2CVA%2CHN%2CHK%2CHU%2CIS%2CIN%2CID%2CIR%2CIQ%2CIE%2CIM%2CIL%2CIT%2CJM%2CJP%2CJE%2CJO%2CKZ%2CKE%2CKI%2CKP%2CKR%2CKW%2CKG%2CLA%2CLV%2CLB%2CLS%2CLR%2CLY%2CLI%2CLT%2CLU%2CMO%2CMK%2CMG%2CMW%2CMY%2CMV%2CML%2CMT%2CMH%2CMQ%2CMR%2CMU%2CYT%2CMX%2CFM%2CMD%2CMC%2CMN%2CMS%2CMA%2CMZ%2CMM%2CNA%2CNR%2CNP%2CNL%2CAN%2CNC%2CNZ%2CNI%2CNE%2CNG%2CNU%2CNF%2CMP%2CNO%2COM%2CPK%2CPW%2CPS%2CPA%2CPG%2CPY%2CPE%2CPH%2CPN%2CPL%2CPT%2CPR%2CQA%2CRE%
The regexp i tried and works externally :
^\/1\.0\/manage\/bu\/ca\?token=.*seg=.*partner=98765432.*
Thank you
Haim Ari / SysOps Manager
M: 972.584563032 / T: 972.722288367
From: Aleksandar Lazic
Sent: Friday, July 20, 2018 1:03 AM
To: Haim Ari
Cc: haproxy@formilux.org
Subject: Re: Regexp
Hi.
On 18/07/2018 13:10, Haim Ari wrote:
>Hello,
>
>Trying to set backend by regexp
>
>This regexp works outside of haproxy
>
>String:
>
>/1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789
>
>Regexp:
>
>^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789
>
>What is the right syntax for this in haproxy ?
I would use
https://regex101.com/r/TjH7Ul/1/
^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789
and backref \1 \2
But that's just a wild guess as the information's from you are very small.
Which version of haproxy (haproxy -vv)?
Which use case do you have?
http-request/http-response/acl/..?
Some config snipped would also help a little bit ;-).
>Thank you
Best regards
Aleks
Re: Regexp
Version: HA-Proxy version 1.8.1-1ppa1~xenial 2017/12/04 Use case: Need to direct these path_reg to a none default backend req: /1.0/manage/bu/ca?token=68b6f68b6f68b6f68b6f=123456789=987654321=1=CP=AF%2CAX%2CAL%2CDZ%2CAS%2CAD%2CAO%2CAI%2CAQ%2CAG%2CAR%2CAM%2CAW%2CAU%2CAT%2CAZ%2CBS%2CBH%2CBD%2CBB%2CBY%2CBE%2CBZ%2CBJ%2CBM%2CBT%2CBO%2CBA%2CBW%2CBV%2CBR%2CIO%2CBN%2CBG%2CBF%2CBI%2CKH%2CCM%2CCA%2CCV%2CKY%2CCF%2CTD%2CCL%2CCN%2CCX%2CCC%2CCO%2CKM%2CCG%2CCD%2CCK%2CCR%2CCI%2CHR%2CCU%2CCY%2CCZ%2CDK%2CDJ%2CDM%2CDO%2CEC%2CEG%2CSV%2CGQ%2CER%2CEE%2CET%2CFK%2CFO%2CFJ%2CFI%2CFR%2CGF%2CPF%2CTF%2CGA%2CGM%2CGE%2CDE%2CGH%2CGI%2CGR%2CGL%2CGD%2CGP%2CGU%2CGT%2CGG%2CGN%2CGW%2CGY%2CHT%2CHM%2CVA%2CHN%2CHK%2CHU%2CIS%2CIN%2CID%2CIR%2CIQ%2CIE%2CIM%2CIL%2CIT%2CJM%2CJP%2CJE%2CJO%2CKZ%2CKE%2CKI%2CKP%2CKR%2CKW%2CKG%2CLA%2CLV%2CLB%2CLS%2CLR%2CLY%2CLI%2CLT%2CLU%2CMO%2CMK%2CMG%2CMW%2CMY%2CMV%2CML%2CMT%2CMH%2CMQ%2CMR%2CMU%2CYT%2CMX%2CFM%2CMD%2CMC%2CMN%2CMS%2CMA%2CMZ%2CMM%2CNA%2CNR%2CNP%2CNL%2CAN%2CNC%2CNZ%2CNI%2CNE%2CNG%2CNU%2CNF%2CMP%2CNO%2COM%2CPK%2CPW%2CPS%2CPA%2CPG%2CPY%2CPE%2CPH%2CPN%2CPL%2CPT%2CPR%2CQA%2CRE% The regexp i tried and works externally : ^\/1\.0\/manage\/bu\/ca\?token=.*seg=.*partner=98765432.* Thank you Haim Ari / SysOps Manager M: 972.584563032 / T: 972.722288367 From: Aleksandar Lazic Sent: Friday, July 20, 2018 1:03 AM To: Haim Ari Cc: haproxy@formilux.org Subject: Re: Regexp Hi. On 18/07/2018 13:10, Haim Ari wrote: >Hello, > >Trying to set backend by regexp > >This regexp works outside of haproxy > >String: > >/1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789 > >Regexp: > >^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789 > >What is the right syntax for this in haproxy ? I would use https://regex101.com/r/TjH7Ul/1/ ^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789 and backref \1 \2 But that's just a wild guess as the information's from you are very small. Which version of haproxy (haproxy -vv)? Which use case do you have? http-request/http-response/acl/..? Some config snipped would also help a little bit ;-). >Thank you Best regards Aleks
Re: Regexp
Hi. On 18/07/2018 13:10, Haim Ari wrote: Hello, Trying to set backend by regexp This regexp works outside of haproxy String: /1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789 Regexp: ^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789 What is the right syntax for this in haproxy ? I would use https://regex101.com/r/TjH7Ul/1/ ^\/1\.0\/manage\/bu\/ca\?token=(.*).segId=(.*).partner=123456789 and backref \1 \2 But that's just a wild guess as the information's from you are very small. Which version of haproxy (haproxy -vv)? Which use case do you have? http-request/http-response/acl/..? Some config snipped would also help a little bit ;-). Thank you Best regards Aleks
Regexp
Hello, Trying to set backend by regexp This regexp works outside of haproxy String: /1.0/manage/bu/ca?token=68bf68bf68bf68bf68bf=1212121212=123456789 Regexp: ^\/1\.0\/manage\/bu\/ca\?token=.*.segId=.*=123456789 What is the right syntax for this in haproxy ? Thank you
