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

; - BUG : 51d: In Hash Trie, multi header matching was affected by the > header names stored globaly. That one clearly violates the commit message guidelines, but it caused an interesting result for the bot. I believe such messages are equivalent to as MINOR, no? Best regards Tim Düsterhus

Re: Small question regarding the sub-dir match (i.e. `-m dir`) with regard to "rooted" patterns

Ciprian, Am 11.03.19 um 12:15 schrieb Ciprian Dorin Craciun: > On Mon, Mar 11, 2019 at 1:12 PM Tim Düsterhus wrote: >> I filed an issue to look into this: >> https://github.com/haproxy/haproxy/issues/61 > > > Thanks. (I didn't knew about the GitHub issues as bein

Re: Small question regarding the sub-dir match (i.e. `-m dir`) with regard to "rooted" patterns

Ciprian, Am 11.03.19 um 12:04 schrieb Ciprian Dorin Craciun: > I would strongly suggest adding an explicit warning in the > documentation about this pitfall. I filed an issue to look into this: https://github.com/haproxy/haproxy/issues/61 Best regards Tim Düsterhus

Re: Small question regarding the sub-dir match (i.e. `-m dir`) with regard to "rooted" patterns

documentation only talks about a slash-delimited value, not about being at the beginning. The latter requirement would be redundant with the the prefix match: `-m beg`. Conclusion: It works as documented. Best regards Tim Düsterhus

Re: haproxy segfault

arly has passed and 1.9 already has accumulated a bunch of already backported fixes and I guess that there are even more in dev. Best regards Tim Düsterhus

Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression

ion exceeds a certain level. The handling of OOMs in the remaining code is not relevant then, because brotli is artificially limited to a (way) lower memory limit that leaves space for other parts. Best regards Tim Düsterhus

Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression

Willy, Am 27.02.19 um 05:12 schrieb Willy Tarreau: > Hi Tim, > > On Tue, Feb 26, 2019 at 06:16:12PM +0100, Tim Düsterhus wrote: >> Willy, >> >> Am 13.02.19 um 17:57 schrieb Tim Duesterhus: >>> *snip* >> >> Are you able to give some (first, bas

Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression

Willy, Am 13.02.19 um 17:57 schrieb Tim Duesterhus: > *snip* Are you able to give some (first, basic) feedback on this patch already? Best regards Tim Düsterhus

Re: Wrong sha256 checksum for HAProxy 1.8 and 1.9?

Cyril, Am 26.02.19 um 14:10 schrieb Tim Düsterhus: > Am 26.02.19 um 13:29 schrieb Cyril Bonté: >> Well, this is more a browser bug than a misconfiguration. But for now, the >> configuration requires a workaround to not use "Content-Encoding: gzip" for &

Re: http2-issue with http2 enabled on frontend and on backend

n you provide a simple example configuration that reproduces the segmentation fault for us to reproduce? Best regards Tim Düsterhus

Re: Wrong sha256 checksum for HAProxy 1.8 and 1.9?

m/a/960710/107543) indicates that this is not a browser bug, but rather actual double compression. Best regards Tim Düsterhus

Re: Wrong sha256 checksum for HAProxy 1.8 and 1.9?

P/1.1 200 OK > < date: Tue, 26 Feb 2019 11:09:30 GMT > < server: Apache > < last-modified: Wed, 06 Feb 2019 13:51:45 GMT > < etag: "54259f-23faaf-5813a06cd63c6" > < accept-ranges: bytes > < content-length: 2357935 > < content-type: application/x-tar > < > { [16149 bytes data] > 100 2302k 100 2302k0 0 1138k 0 0:00:02 0:00:02 --:--:-- 1138k > * Connection #0 to host www.haproxy.org left intact > 8483fe12b30256f83d542b3f699e165d8f71bf2dfac8b16bb53716abce4ba74f - Best regards Tim Düsterhus

Re: Idea for the Wiki

/Test.md -> https://github.com/TimWolla/test/wiki/Test There are two pages called `Test` in the sidebar, but only the one in `Folder` can be accessed. The one in `Folder2` can't. I suggest to create new pages using the web interface only to make sure it can handle it. Editing can be done using g

Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression

proves compression rate further (I guess it selects a different dictionary): https://github.com/google/brotli/blob/5805f99a533a8f8118699c0100d8c102f3605f65/docs/encode.h.3#L197-L204 Best regards Tim Düsterhus

Re: Compilation fails on OS-X

/github.com/haproxy/haproxy/issues/42 Best regards Tim Düsterhus

Re: possible use of unitialized value in v2.0-dev0-274-g1a0fe3be

out holes terminated by an empty string. Thus either: 1. The Condition is false, then the value must be initialized or 2. The Condition is true, then the loop is exited. Thus I believe this is a false-positive. Best regards Tim Düsterhus

Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

Willy, Am 29.01.19 um 12:47 schrieb Tim Düsterhus: > I initially implemented it as a `goto error`. That disables the actual > compression of the body. Unfortunately the `Content-Encoding` header is > already modified, thus the client expects gzip, but receives plain data. > I co

Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

d, thus the client expects gzip, but receives plain data. I could mitigate that by modifying the ETag header first which is the most likely one to fail. Ideally the http_set_comp_reshdr / htx_set_comp_reshdr functions run atomically, if one header fails to be modified all of the headers revert to their original values. But this is currently not the case. What do you think? Best regards Tim Düsterhus

Re: haproxy 1.9.2 with boringssl

/ RHEL I don't use at all. > Any Idea for the other failed tests? No idea. Best regards Tim Düsterhus > - > ## Starting vtest ## > Testing with haproxy version: 1.9.2 > #top TEST ./reg-tests/http-rules/h2.vtc FAILE

Re: haproxy 1.9.2 with boringssl

uot; failed The difference here is that the test expects an IPv6 address that's not maximally compressed, while you get a IPv6 address that *is* maximally compressed. I would guess that this is the difference in behaviour between glibc and musl (as you are using an Alpine container). Best regards Tim Düsterhus

Re: Replicated stick tables have absurd values for conn_cur

s well. > > I've checked the rest of the related code for variations and only this > key works like a gauge, up and down. The other ones in the worst case will > simply lose some counts but will not face such a problem. Okay. I guess my patch is the best short term solution then. Best regards Tim Düsterhus

Re: Replicated stick tables have absurd values for conn_cur

fine with the patch it's fine, I guess. A real solution definitely requires breaking compatibility with the current peer protocol. Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

rk of testing with the templates (you can add me as a Co-authored-by: Tim Düsterhus at the bottom). Lukas: You probably need to update the "bug" label to "type: bug" in the Bug.md template. 4. Someone creates a first issue titled "Add issue templates". 5. The patch is m

Re: haproxy issue tracker discussion

fects: dev" is not there anymore then pending-backport is implied > by ("affects: 1.x" and not "affects: dev"). This even works for bugs > that only affect older branches. Does it? What if a bug is found that only affects the current stable branch, but not dev, because some refactoring "accidentally" fixed it? I don't strongly care either way, though. A "pending-backport" is only useful for the developers, not the end user. And if you don't consider that label useful we just don't add it. Best regards Tim Düsterhus

Re: Replicated stick tables have absurd values for conn_cur

d out, whether the segfaults are caused by the patch and where exactly it segfaults? Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

much how it works. You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the repository: https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md see: https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ >> status: pending-backport > > I think this one is implied by the presence of "affects:" Not necessarily. "affects" without "pending-backport" probably needs more work finding the issue first, while "pending-backport" can be as easy as a cherry-pick. Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

gt; - a rough consensus of the process (like the sequence above) It's looking good. I believe the initial "needs-triage" label can be added using the template: https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ (step 5). Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

ntrated together, users can see that their version remains bogus > because we don't know how to backport the fix but the next one is fixed > so it might be time to upgrade, and there's much less info duplication > leading to the inevitable consistency that comes from it. I guess that will work then. Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

ber be added to create a > corelation > to the issue with `#`. > https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests Yes, this should be done. Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

t; Subject: Backport 1.7: If I foo then haproxy replies with bar instead of baz > > This is a follow-up issue, because #123 is not yet fixed for haproxy 1.7. 4. Developer backports the commit, closing the follow-up issues whenever he did so (this probably can be automated as well. If a Backport-To: 1.7 line appears in the 1.7 branch the matching issue will be closed). Best regards Tim Düsterhus

Re: haproxy issue tracker discussion

point. > > So unless anyone has a better idea for now, and if you're feeling brave > enough, let's give it a try. > It's probably impossible to build something absolutely perfect without real world data points. If a pain point arises it can be specifically worked on. Currently this discussion is completely hypothetical. Best regards Tim Düsterhus

Re: coredump in h2_process_mux with 1.9.0-8223050

t does not need to be exposed for the whole world to see :-) > I don't have any idea what the exact circumstance request/response was.. What might be of interest is the configuration: Are you using HTX, Compression, Lua or something like that? Best regards Tim Düsterhus > Anyhow i updated my s

Re: haproxy issue tracker discussion

ople are actually are able to research whether their issue is already known / a duplicate and possible workarounds. The mail archive is not really accessible. > With that said at the moment we don't have anything and the situation is > not better than having a suboptimal tool. I agree. Best regards Tim Düsterhus

Re: haproxy reload terminated with master/worker

th -Ws? haproxy informs systemd when a reload starts and when it is finished using the sd_notify protocol: https://www.freedesktop.org/software/systemd/man/sd_notify.html#RELOADING=1 Best regards Tim Düsterhus

Re: Replicated stick tables have absurd values for conn_cur

even sure if my understading is correct, but it's task currently out of > my reach. > Should I do a bug report somewhere? :) > I suspect that the developers will notice this thread. A proper issue tracker is a wish of mine as well (https://www.mail-archive.com/haproxy@formilux.org/

Re: Replicated stick tables have absurd values for conn_cur

sends 0/2 to A (A=?, B=0) - Kill connection to B (A=?, B=-1) - Peer B sends -1 to A (A=-1, B=-1) An easy fix would probably be skipping the decrement if the value is already 0. The counter will be off either way, though. Best regards Tim Düsterhus

Re: 1.9.1 coming soon (well, relatively soon)

essage-ID 20180525161044.ga6...@1wt.eu: https://www.mail-archive.com/haproxy@formilux.org/msg30139.html Both as a user and a developer that got a few patches into haproxy I'm still missing a proper issue tracker :-) And continuous integration would certainly be helpful as well, no that we have a bug of

Re: [PATCH] CLEANUP: http: Fix typo in init_http's comment

ror message. > */ > int init_http(char **err) > While cleaning up my local branches I noticed that this patch is not yet merged and probably slipped through. Message-ID: 20180915224230.12922-1-...@bastelstu.be Archive : https://www.mail-archive.com/haproxy@formilux.org/msg31231.html Best regards Tim Düsterhus

Re: BUG: Warning: invalid file descriptor -1 in syscall close()

it's not yet on the > documentation file but that's the way it's documented in the usage message. > I've taken the usage from your commit message in commit e736115d3aaa38d2cfc89fe74174d7e90f4a6976 :-) Best regards Tim Düsterhus

Re: [PATCH] BUG/MINOR: cli: Fix memory leak

.sock -Ws -f ./haproxy.cfg with an empty configuration file to find the issues my patch fixes. Best regards Tim Düsterhus

Re: lua haproxy-auth-request - round 2

e dev tools and look at the request headers, whether there is an Authorization header. Of course oauth_proxy needs to be enabled. I attached a screenshot of Chrome's dev tools. If you send me credentials in private I can take a look myself, if you want. Best regards Tim Düsterhus

Re: [ANNOUNCE] haproxy-1.9-dev3

gt; cc1: all warnings being treated as errors > make: *** [Makefile:929: src/hlua.o] Error 1 > make: *** Waiting for unfinished jobs > cc1: all warnings being treated as errors > make: *** [Makefile:929: src/ssl_sock.o] Error 1 Best regards Tim Düsterhus

Re: lua haproxy-auth-request - round 2

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

Re: haproxy-auth-request

Hi all, Am 02.09.2018 um 22:47 schrieb Tim Düsterhus: >> Lua function 'auth-request': runtime error: attempt to yield across a >> C-call boundary from [C] field 'request', >> /Computerisms/config/etc/haproxy.auth.lua:95 C function line 56. > Someone reported the same error

Re: haproxy-auth-request

p lua ii liblua5.3-0:amd64 5.3.3-1 amd64Shared library for the Lua interpreter version 5.3 ii lua-socket:amd64 3.0~rc1+git+ac3201d-4 amd64TCP/UDP socket library for the Lua language Bob, can you give your `haproxy -vv`? Best regards Tim Düsterhus

Re: haproxy-auth-request

lb in there it hasn't blinded me yet. >> I believe the issue might be that your version of LuaSocket calls `settimeout` differently that I anticipated in haproxy-auth-request. What version of LuaSocket are you using? Can you give your configuration? 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] 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 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

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: [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

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: [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

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: [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 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: 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: 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: 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: 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: [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: 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: 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: Show: h-app-proxy – Application server inside haproxy

. 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: 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: 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

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] 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

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] 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] 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

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: 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

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

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

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: 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

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: 1.9dev LUA shows partial results from print_r(core.get_info()) after adding headers ?

et:send()` below the second print_r. I also could not reproduce the issue if the Content-Length header specifies a length *greater* than the actual length of the content. I could however reproduce it, if the Content-Length header specifies a length *smaller* than the actual length of the content.

Re: 1.9dev LUA register_task to function that ends performs a core dump..

= generic > CC = gcc > CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv > -fno-strict-overflow -Wno-unused-label > OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 > USE_LUA=1 USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1 Best regards Tim Düsterhus

Re: DNS resolver and mixed case responses

to be somewhat expected according to a quick Google search. Best regards Tim Düsterhus

Re: Why maxconn value can have a negative value?

at it also take a look at `struct listener`, which also contains a `maxconn` member. Best regards Tim Düsterhus

Re: Why maxconn value can have a negative value?

axconn` are sometimes unsigned and sometimes signed. Willy, global.maxconn is signed, while proxy.maxconn is unsigned. Is this intentional? Best regards Tim Düsterhus

Re: lua socket api settimeout in seconds vs. milliseconds

Willy, Am 08.03.2018 um 21:15 schrieb Thierry Fournier: > 3 new patch in attachement to consider for the initial subject of > this thread. > did you miss these patches from Thierry to the Lua subsystem? Best regards Tim Düsterhus

Re: patch: fix build when USE_THREAD is not defined

loop as part of it's optimizations. Best regards Tim Düsterhus

Re: add header into http-request redirect

s I missed the announce). > Expect-CT technically still is a draft [1], but it is implemented since Google Chrome 61 [2]. Personally I know that Cloudflare already is setting that header on their responses. HPKP is deprecated in Google Chrome and header processing will be removed for Chrome

Re: add header into http-request redirect

: - Expect-CT - Public-Key-Pins (a.k.a. HPKP) Both are deeply related to HSTS due do being TLS security headers. The latter is being deprecated by the browsers, because of footgun issues, though. The former is fairly new. Best regards Tim Düsterhus

Re: add header into http-request redirect

ng a special case where really no special case should be needed and would require me to update headers in two places. But I'm also not deep enough in haproxy's internals to know how hard it would be treating the `redirect` like a regular backend response and applying the regular http-response logic there. Best regards Tim Düsterhus

  1   2   >