Re: Backend: Multiple A records

ntainer like this: $ docker exec -it knot bash Best regards Tim Düsterhus

Re: Backend: Multiple A records

eet my requirements perfectly. I won't have control over the IP addresses assigned in the DNS. Thanks for your replies so far! Looking forward to it. Best regards Tim Düsterhus

Re: Backend: Multiple A records

NS server is completely under my control, returns a low TTL and is able to update the list of nodes almost instantly after a node goes up or down. Best regards Tim Düsterhus

Re: Backend: Multiple A records

Thanks! Best regards Tim Düsterhus

Backend: Multiple A records

@ns-containers.example.com nginx.containers.example.com 172.17.0.5 172.17.0.6 Is there a configuration setting / workaround for this? If not: Is this something that could be introduced in a future version or does it conflict with a design decision? Best regards Tim Düsterhus

Re: [ANNOUNCE] experimental spam filtering

Hi On 22.09.2016 17:41, Willy Tarreau wrote: For now it only adds the "x-bogosity" header to the e-mail and still delivers it so that I can monitor the activity, but the purpose is to very quickly switch to dropping those marked as spam (which are the majority of those people complain about).

Re: Backend: Multiple A records

ecords at nginx.containers.example.com, great! It also brought the backends down once the record disappeared, also great! Unfortunately it still sent the requests to a single nginx backend only, instead of using all the available IP addresses. Did I configure something wrong? Best regards Tim Düsterhus

Re: Backend: Multiple A records

ted 6-months release. So this will have to > wait for 1.8 or later, until someone has time to complete this feature. Fair enough, thanks for the heads up. Best regards Tim Düsterhus

Re:

Hi Whoops, please forgive my missing subject. I thought git send-email would automatically use the Subject line of the commit as the Subject of the introductory mail. Lesson learned. Best regards Tim Düsterhus

Re: [PATCH] DOC: Spelling fixes

thought about whether to make my name ASCII safe or not. I should have. Next time :-D > The only place where alternative charsets are tolerated is in your name in the commit message, but it's at your own risk as it can be mangled during the merge. Best regards Tim Düsterhus

Re: [ANNOUNCE] haproxy-1.7.5

equest. In fact I did so myself to get the 1.7.x release onto Docker Hub in the past: https://github.com/docker-library/haproxy/pull/35 Best regards Tim Düsterhus

Removed health check in combination with load-server-state-from-file (Bug)

Hi I run haproxy with 'load-server-state-from-file'. Before reloading haproxy I dump the state using: echo show servers state |nc -U admin.sock > /etc/haproxy/state/global I noticed a buggy behaviour with this: 1. Check that the backend is 'DOWN'. 2. Dump the state using the command above (the

Re: Compare against variable string in ACL

Holger, On 08.05.2017 11:37, Holger Just wrote: > We use basically this configuration snippet in production for quite some > years now and it works great. > while not exactly pretty, it definitely works fine. Thank you. Best regards Tim Düsterhus

Compare against variable string in ACL

matching var(txn.rheader) -i %[ssl_fc_sni] But it seems that '%[ssl_fc_sni]' is interpreted as a literal string here, instead of the provided SNI value. I basically want an ACL that matches if 'hdr(host) == ssl_fc_sni' to use programming language terminology. Best regards Tim Düsterhus

Re: Removed health check in combination with load-server-state-from-file (Bug)

Hi as I did not receive any reply at all to my email from Aug 13 I thought I resend it (Quoted below). Can anyone at least verify that my bug report is valid? :-) Tim Am 13.08.2017 um 13:19 schrieb Tim Düsterhus: > Hi > > I run haproxy with 'load-server-state-from-file'. Before

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

aproxy's internals they look good to me. Just one thing: At the top of `static void mworker_reload(void)` the Environment is modified using: > setenv("HAPROXY_MWORKER_REEXEC", "1", 1); Is it necessary to reset that value in case of `execvp` failure? You don't seem to do so. Best regards Tim Düsterhus

[PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

From: Tim Duesterhus If haproxy is started using the name of the binary only (i.e. not using a relative or absolute path) the `execv` in `mworker_reload` fails with `ENOENT`, because it does not examine the `PATH`: [WARNING] 315/161139 (7) : Reexecuting Master process

Fix re-exec when haproxy is started from PATH

This is a bug I noticed when preparing the official Dockerfiles for haproxy 1.8, as they make use of the PATH [1]. This is my first time contribution of actual code. I'm not sure whether my patch is the best solution for this issue: Please be extra careful when reviewing. And please let me know

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 11:11 schrieb William Lallemand: > On Sun, Nov 19, 2017 at 03:10:21AM +0100, Tim Düsterhus wrote: >> +KillSignal=USR1 > > In my opinion this part is a problem, it won't stop the process immediatly > but wait for session to be finished. It will

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

n when it's not built. > May I suggest the following: If haproxy is *not* compiled with the `USE_SYSTEMD` option it checks for the existence of the `NOTIFY_SOCKET` environment variable and refuses start up, if it is defined. Then `Type=notify` will "just work" if haproxy is compiled with

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

or -W for > type=forking for example). Is it possible to modify the unit file depending on the build flags? Then I absolutely agree that `Type=notify` should be taken out if `USE_SYSTEMD` is not set. See my sibling mail for another suggestion to avoid the "silent failure" when `USE_SYSTEM

Re: [ANNOUNCE] haproxy-1.8-rc4

+--------+ > > Best regards Tim Düsterhus

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

of the non-Linux or non-systemd systems. The function calls themselves won't cause issues as outlined above. I hope I was able to give a good overview so that you can decide on the proper course going forward. Thanks! Tim Düsterhus

[PATCH v2 0/1] Add systemd `Type=notify` support

Aleksandar, I added `USE_SYSTEMD` to the `BUILD_OPTIONS` and moved the whole block down below the `USE_WURFL` block to match the ordering in the comment at the top of the file. I also noticed a blank line I added by accident. I removed that one in this new patch also. Thanks Tim Düsterhus Tim

[PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

From: Tim Duesterhus This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note

[PATCH] MEDIUM: mworker: Add systemd `Type=notify` support

This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note however that reloading a daemon by

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

William, Am 20.11.2017 um 13:45 schrieb William Lallemand: > On Mon, Nov 20, 2017 at 12:55:06PM +0100, Tim Düsterhus wrote: >> May I suggest the following: If haproxy is *not* compiled with the >> `USE_SYSTEMD` option it checks for the existence of the `NOTIFY_SOCKET` >>

Re: [PATCH v2 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

nstead of not sending the READY=1 notification) if one uses the provided unit file *without* compiling with USE_SYSTEMD. Thus in my opinion a separate -Ws option will increase cognitive load (which option should I use?) for next to no benefit. Best regards Tim Düsterhus

[PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

From: Tim Duesterhus This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note

[PATCH v3 0/1] MEDIUM: mworker: Add systemd `Type=notify` support

Willy, > I really don't like this at all, because it means that we'll annoy all > the happy people who are not forced to suffer from systemd, ie basically > all those not running on a recent linux distro, simply because we're starting > to declare that certain environment variables only belong to

Re: [PATCH v2] BUG/MINOR: systemd: ignore daemon mode

ns(+), 2 deletions(-) > *snip* I agree that this is a good solution to the problem. I tested your patch and can confirm it is working fine. Best regards Tim Düsterhus

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

possibly fail for other reasons in the future. > Willy, could you please apply this patch? thanks > Thanks! Tim Düsterhus

Re: Error in `haproxy': munmap_chunk(): invalid pointer:

ng to delete the tarball from my server then. Thanks! Tim Düsterhus

Re: Error in `haproxy': munmap_chunk(): invalid pointer:

ixed (and no matter how wrong configuration is: haproxy should not crash like that) I am curious: Why would I want to run IPv4 only in 2017 when my machine has a fully working dual stack IPv6 connection? Best regards Tim Düsterhus

Error in `haproxy': munmap_chunk(): invalid pointer:

40c2000-7fda740c3000 rw-p 00:00 0 > 7ffc98439000-7ffc9845a000 rw-p 00:00 0 > [stack] > 7ffc98548000-7ffc9854a000 r--p 00:00 0 > [vvar] > 7ffc9854a000-7ffc9854c000 r-xp 00:00 0

Re: [PATCH 1/2] DOC: mworker: Update messages referencing exit-on-failure

blem. > Okay, updated patch sent (because I was not sure whether you / Willy would edit it yourselves or not). Best Tim Düsterhus

[PATCH 1/2] DOC: mworker: Update messages referencing exit-on-failure

From: Tim Duesterhus Commit 4cfede87a313456fcbce7a185312460b4e1d05b7 removed `exit-on-failure` in favor of `no-exit-on-failure`, but failed to update references to the former in user facing messages. This should be backported to haproxy 1.8. --- src/cfgparse.c | 2 +-

[PATCH 2/2] DOC: mworker: Improve wording in `void mworker_wait()`

From: Tim Duesterhus Replace "left" / "leaving" with "exit" / "exiting". --- src/haproxy.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/haproxy.c b/src/haproxy.c index 5f3e3948d..528531f79 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@

Re: Domain fronting

thread also. Depending on you exact set-up of certificates you might or might not break legitimate requests when preventing domain fronting. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

y here it doesn't fit for the case where you > don't block. And it's very important not to violate such guarantees as > some people really rely on them. For example during forensics after an > intrusion attempt on your systems, you really want to know if the attacker > managed to retrieve something or not. > Understood. I'll see whether I manage to prepare a first stab of a patch this week. Best regards Tim Düsterhus

Re: stable-bot: WARNING: 13 bug fixes in queue for next release

> everyone else synchronise with this. IMO for synchronization the date needs to be reliable. Best regards Tim Düsterhus

Show: h-app-proxy – Application server inside haproxy

Demo : https://bl.duesterhus.eu/20180511/demo/DWhxJf2Gpt Hacker News: https://news.ycombinator.com/item?id=17049715 Best regards Tim Düsterhus PS: Don't use this at home or at work even :-)

Re: Fwd: [haproxy/haproxy] BUG/MAJOR: server: Segfault after parsing server state file. (0bedb8a)

Willy,(writing from my phone, blame it, if I mess up the quotes) Am 23.05.2018 11:20 vorm. schrieb Willy Tarreau : Well, please post here instead, it's where people are present and follow the activity. I'm adding Fred in CC since he's the one who fixed the crash, and Baptiste as

Fwd: [haproxy/haproxy] BUG/MAJOR: server: Segfault after parsing server state file. (0bedb8a)

Hi list the following comment has been posted to GitHub on commit 0bedb8ac90ffdf1498a999c44d1c91556fb726ee https://github.com/haproxy/haproxy/commit/0bedb8ac90ffdf1498a999c44d1c91556fb726ee#commitcomment-29087381 Best regards Tim Düsterhus Weitergeleitete Nachricht Betreff

Re: haproxy 1.9 status update

any of these, will have to check closer). It may even be > used for Aleks' docker images if that makes sense at all (I don't > know). GitHub: You are able to attach downloads to git tags. This probably would imply having all the maintenance repositories as separate branches in a single repository (i.e. not master in haproxy-1.8.git, but 1.8.x in haproxy.git). Best regards Tim Düsterhus

Re: Show: h-app-proxy – Application server inside haproxy

. Best regards Tim Düsterhus

Re: haproxy bug: healthcheck not passing after port change when statefile is enabled

.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectoryPreserve=). Best regards Tim Düsterhus

Re: HAProxy 1.8.x not serving errorfiles with H2

efault errors. You need to prefix HTTP response headers. Something like this should work [2]: > HTTP/1.0 503 Service Unavailable > Cache-Control: no-cache > Connection: close > Content-Type: text/html Best regards Tim Düsterhus [1] https://cbonte.github.io/haproxy-dconv/1.8/confi

Re: [PATCH v2] MINOR: http: Log warning if (add|set)-header fails

tion by status code. > The joys of copy and paste. Thank you. I also noticed that you adapted the stats page already. As I did not note anything in the commit message: It should be discussed whether this patch(es) should be backported. It looks fairly safe too me and could be helpful for

Re: remaining process after (seamless) reload

y > ● haproxy.service - HAProxy Load Balancer >Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor > preset: enabled) >Active: active (running) since Tue 2018-05-29 21:27:58 CEST; 1s ago Best regards Tim Düsterhus

Re: remaining process after (seamless) reload

nd information like the number of requests handled to the master to be able to display them in SystemD [1] Best regards Tim Düsterhus [1] https://www.freedesktop.org/software/systemd/man/sd_notify.html#STATUS=%E2%80%A6

Re: [PATCH 1/1] BUG/MAJOR: stick_table: Complete incomplete SEGV fix

nstead of moving it into the if, because it looks more like sample_conv_table_conn_cur that way (see my other email). Best regards Tim Düsterhus

Re: [PATCH 1/1] BUG/MAJOR: stick_table: Complete incomplete SEGV fix

_table_conn_cur' (though I forgot to add the `/* key not present */` comment, can you do so when applying?). I believe that you missed the fact that I edited a different function and thus I believe that your remaining points do not apply? Best regards Tim Düsterhus

Re: [Patch] Re: Segfault with haproxy 1.8.10

Hi Am 26.06.2018 um 13:56 schrieb Willy Tarreau: > Your patch is obviously good, I've just merged it. > Should sample_conv_table_trackers also be updated? It also checks whether `ts` is valid, before accessing it, but unconditionally calls stktable_release later on. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

spect (again: see above paragraphs). I want to note at this point that I'm not running haproxy at scale or with serious monitoring. The haproxy instance I'm experiencing this issue with is my personal server, not some company or business one. It runs my mail and some side / hobby projects. My needs or expectations might be different. Best regards Tim Düsterhus

Re: [PATCH] BUG/MINOR, lua/sockets, make lua tasks that are waiting for io suspend until woken up by the a corresponding event.

f what the bug might me. But please check whether I grasped the issue properly. BUG/MINOR: lua: Put tasks to sleep when waiting for data Best regards Tim Düsterhus

http-response set-header is unreliable

: 8.39 2016-06-14 > Running on PCRE version : 8.39 2016-06-14 > PCRE library supports JIT : yes > Built with zlib version : 1.2.8 > Running on zlib version : 1.2.8 > Compression algorithms supported : identity("identity"), deflate("deflate"), > raw-deflate("deflate"), gzip("gzip") > Built with network namespace support. > > 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 filters : > [SPOE] spoe > [COMP] compression > [TRACE] trace Any ideas? Best regards Tim Düsterhus

Re: Use SNI with healthchecks

e to put such a fetch and what parameters to set I'd appreciate it. Or tell me that such a fetch is stupid, because it mixes information from different layers. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

non-rewrites would cause. Clearly the body must be able to span multiple buffers already, otherwise I would not be able to send bodies greater than 16kB. Will it need to allocate more buffers to do the same work, because every single one is smaller? Best regards Tim Düsterhus

Re: http-response set-header is unreliable

are that plans can change :-) > Anyway we need to address the lack of error checking, and I really predict > some breakage here :-/ > I'd start of with *logging* when the call fails for the short term. Users that see it failing can look into their logs to find out what knobs to turn. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

it affect two headers at once? If the length is right below the limit intuitively only the very last header should be affected. A last: Maybe it makes sense to create a log message if this limit is hit instead of silently ignoring (security critical!) response headers? Best regards Tim Düsterhus

Re: http-response set-header is unreliable

aproxy-dconv/1.9/configuration.html#3.2-tune.bufsize tune.maxrewrite is documented to "prevent addition of headers": https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#3.2-tune.maxrewrite So it works like documented. But that does not mean that the current documented behaviour is a good behaviour. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

gs" columns in the stats page which are unused for > the frontends, we could use it to report a count of such failures. Or we > could add an extra "rewrite" column under "warnings" to report such errors > where they were detected. > As noted above the stats page is useless to me. Most useful to me would be something munin could detect, because it would send me a mail. Actually the first thing I would notice is if haproxy died, because then my mail does not work either. I put haproxy in front of my Dovecot. But that's a bit drastic I think. :-) Best regards Tim Düsterhus

Re: [PATCH] MINOR: Add server name & puid to LUA Server class.

o: +1 for string from me. Best regards Tim Düsterhus

Re: http-response set-header is unreliable

he longer term and thus loses it usefulness. Having a warning_headers_too_big counter and a warning_whatever_there_may_be is stupid, no? I feel that the error counter could / should be re-used for this and just the log message should be added. My munin already monitors the error counts. The `eresp` counter seems to fit: "- failure applying filters to the response.". Best regards Tim Düsterhus

Re: [PATCH] BUG/MINOR, lua/sockets, make lua tasks that are waiting for io suspend until woken up by the a corresponding event.

wrap at lengths between 72 and 76 characters. Personally I just wrap so that it fits my default terminal size of 80x24 characters nicely. And one last thing: Copied, literal, output of tools such as gdb for stack traces should not be wrapped. It should simply exceed the width. Best regards Tim Düsterhus

Re: [PATCH 1/2] BUG/MINOR: lua: Fix default value for pattern in Socket.receive

y, I notice that you did not backport to earlier than 1.8, yet. Do you usually do this shortly before release or did you forget? At least the two MINOR ones should be backported to 1.6 also. Best regards Tim Düsterhus

Re: [PATCH 1/2] BUG/MINOR: lua: Fix default value for pattern in Socket.receive

So > thanks for that ;-) It pays to read the CONTRIBUTING file :-) Best regards Tim Düsterhus

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

it should not work in other places. I'd be grateful if you could verify the correct workings of stick tables, as you already know how they are supposed to work. Thanks Tim Düsterhus

Show: haproxy-auth-request - HTTP access control using subrequests

allows you to decide whether an HTTP request should be allowed or not based on the result of an HTTP request to a backend service. I have also written a blog post if you are curious of the journey behind that script: https://bl.duesterhus.eu/20180119/ Best regards Tim Düsterhus

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

ainly can update the patch when Willy tells me his preference (just move the declaration up or perform the casting). Best regards Tim Düsterhus

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

/8 which don't really touch live code (apart from 5). It would allow me to clean up a bit of my local repository. Best regards Tim Düsterhus

Re: Show: haproxy-auth-request - HTTP access control using subrequests

this script.) haproxy's Socket class is documented to be non-blocking, as explained here: https://www.arpalert.org/haproxy-lua.html#h204 ("Non blocking design"). Most of my article focused on getting the Socket class of haproxy to work, instead of using the native Socket class of Lua for that reason. Best regards Tim Düsterhus

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

Jarno, Willy, Am 15.01.2018 um 14:28 schrieb Jarno Huuskonen: > On Sun, Jan 14, Tim Düsterhus wrote: >>> Have you tested that req.hdr_ip / stick tables work w/both masks ? I >>> used something like: >>> http-request track-sc0 req.hdr_ip(X,1),ipmask(24,64) table te

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

. Best regards Tim Düsterhus

Re: Difference between variables and sample fetches?

018 13:02:30 GMT > Server: ECS (lga/1395) > Content-Length: 345 > Test: 127.0.0.1 > Test2: 127.0.0.1 Is it a bug that they work inside for example http-response set-header (as shown above) as well? Best regards Tim Düsterhus

Re: Difference between variables and sample fetches?

That makes sense. For posterity I'd like to expand this: There also is and (so one probably should grep for `fmt>`, without the leading `<`. Sample fetches seem to be denoted by `` (set-var, set-<src|dst>[-port]) and are also available in ACLs of course. Thank you. Best regards Tim Düsterhus

Re: [PATCH] BUG/MEDIUM: standard: Fix memory leak in str2ip2()

Willy, Am 21.01.2018 um 22:11 schrieb Tim Duesterhus: > Subject: [PATCH] BUG/MEDIUM: standard: Fix memory leak in str2ip2() As I did not receive any answer at all for two weeks: Did you miss this patch? I can resend, if you want. Best regards Tim Duesterhus

Re: trying to undestand (via netstat) how many connections haproxy opens to backends

as an incoming connection to Apache, from haproxy. Best regards Tim Düsterhus

Bug: haproxy fails to build with USE_THREAD=

276: undefined reference to `pl_deref_int' > collect2: error: ld returned 1 exit status > Makefile:898: recipe for target 'haproxy' failed > make: *** [haproxy] Error 1 Best regards Tim Düsterhus

Re: [PATCH] DOC: cfgparse: Warn on option (tcp|http)log in backend

ndled later patches: Thus a friendly reminder in case you missed this one as well. Am I doing something wrong? Should I Cc you for every patch? Best regards Tim Düsterhus [1] Incidentally this patch came 14 minutes after my previous reminder and 8 minutes before your reply to my reminder.

Re: Haproxy 1.8.4 crashing workers and increased memory usage

y default, because they could contain sensitive information. After the next crash you should be able to retrieve a backtrace using gdb. Possibly recompile haproxy with debug symbols for it to be useful. Best regards Tim Düsterhus

Re: Poll: haproxy 1.4 support ?

" are the Debian based ones. This is a convention for "official" [1] Docker images if they have both Debian and Alpine based ones. You can check by clicking the link for e.g. the "latest" image and checking the first line of the Dockerfile. Best regards Tim Düsterhus [1] "Offic

Re: Poll: haproxy 1.4 support ?

configure a `post-receive` hook or set `git config receive.denyCurrentBranch updateInstead` [1] and accept patches like you do for haproxy itself. Best regards Tim Düsterhus [1] See https://github.com/blog/1957-git-2-3-has-been-released for an explanation of that feature.

Re: [ANNOUNCE] haproxy-1.8.13

leased. I'd even like to see PGP signatures, like you already do for the git tags (but not the Tarballs). But this is a greater change than just updating the checksums :-) Best regards Tim Düsterhus

Re: [ANNOUNCE] haproxy-1.8.13

ust the binaries (e.g. tar) on the haproxy.org machine :-) Anyway: I am disgressing here and will patiently await whether or not there will be PGP signatures in the future. Best regards Tim Düsterhus

Re: [ANNOUNCE] haproxy-1.8.13

y.org? I think it's strange that the parts of the release process are distributed onto several machines (one to create the tag, one to create the Tarball). Best regards Tim Düsterhus

Fwd: [haproxy/haproxy] MAJOR: server: make server state changes synchronous again (3ff577e)

the author aware of the list once my email lands in the mail archive. Best regards Tim Düsterhus

Re: [PATCH] BUG/MINOR: lua: Bad HTTP client request duration.

exist, because the hash changed when applying). Frederic: That's why I believe that reg-tests should be provided in the commit fixing the issue, instead of being provided in a separate commit. Best regards Tim Düsterhus

Re: [PATCH] MEDIUM: reset lua transaction between http requests

in my reg-test (with the minor change as requested by Frederic). Best regards Tim Düsterhus

Re: [PATCH] MEDIUM: reset lua transaction between http requests

a date + short slug representing the test description: b_20180828_txn-get-priv-scope.vtc Best regards Tim Düsterhus

Re: URL rewrite

uests https://cloud.example.com/?query in their web browser it gets proxied to a backend running at https://.cloud.example.com/main?query ? Is it possible that there follows a path that you need to preserve: https://cloud.example.com///?query to https://.cloud.example.com/main//?query ? Best regards Tim Düsterhus

Re: [PATCH 1/1] TMP: Add reg-test to check scoping of txn:get_priv()

not added separately. Test + Fix should be an atomic unit. Whoever fixes the actual issue should just copy the reg-test into their commit, fix your remark and add me to the commit message as Co-authored-by: Tim Düsterhus :-) > Also note that -run is a shorcut for -start -wait. Good to know, t

Re: [PATCH] MINOR: Generate sha256 checksums in publish-release

ithout having to special case branches with and without sha256. Best regards Tim Düsterhus

Re: [PATCH] BUG/MINOR: http: Set brackets for the unlikely macro at the right place

crash: http://git.haproxy.org/?p=haproxy.git;a=commit;h=45be38c9c7ba2b20806f2b887876db4fb5b9457c You might want to review all the `unlikely` / `likely` invocations, now that it happened twice. Best regards Tim Düsterhus

Re: [PATCH] MEDIUM: proxy_protocol: Send IPv4 addresses when possible

t. based on the overall lack of responses I assume that you are busy. I just want to make sure that this patch / bug report did not slip through the cracks. A short acknowledgement that you received it would be great, if you are currently unable to take a deeper look at it. Best regards Tim Düsterhus

Re: [PATCH] MEDIUM: proxy_protocol: Send IPv4 addresses when possible

ioned above) is, that I did not want to touch the actual logic. > I'm personally fine with something roughly like this. Lukas, I'm interested > in your opinion on this one, as I *think* it addresses the issues without > introducing new ones. We could even think about backporting this. > Best regards Tim Düsterhus

Re: [PATCH] MEDIUM: proxy_protocol: Send IPv4 addresses when possible

e_proxy_line() now always operates on a copy of `struct connection remote`. I could not find a better solution and already thought hard about the current version. Best regards Tim Düsterhus

Re: haproxy-auth-request

because all the request headers are forwarded to the backend. Best regards Tim Düsterhus

Re: haproxy-auth-request

Hi all, Am 04.09.2018 um 13:50 schrieb Tim Düsterhus: > Someone reported the same error in the issue tracker on GitHub: > https://github.com/TimWolla/haproxy-auth-request/issues/4 > The issue in the bug tracker was caused by an old version of lua-socket. Unfortunately the author of l

  1   2   3   4   5   6   7   8   9   >