Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Willy Tarreau
Hi Ben, On Wed, Apr 24, 2019 at 06:20:16PM +0200, Christopher Faulet wrote: > Le 24/04/2019 à 17:56, Ben Shillito a écrit : > > Hi Willy, > > > > Thanks for the update. We will take a look and get a patch over to you. > > > > Hi, > > Ben, the function _51d_fetch() is not HTX aware. Take > a

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Willy Tarreau
On Wed, Jun 12, 2019 at 08:52:53AM +, Ben Shillito wrote: > Hi Willy, > > This unfortunately fell down our list of priorities in the last few weeks. Oh I certainly can understand, and I'm sorry I forgot about it so I didn't ping you earlier. > However, as this is a bit more urgent now with

Re: Idea + question regarding the build targets

2019-06-12 Thread Tim Düsterhus
Willy, Am 12.06.19 um 07:38 schrieb Willy Tarreau: > So my questions are : > - does anybody think it's a bad idea ? I do. Even if the Linux distribution in question theoretically supports a certain feature you are: 1. Not guaranteed that the development headers are installed. As a specific

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Ben Shillito
Hi Willy, Great, thanks for those changes, and good spot. I agree that this is a significant step forward, and having the entire codebase testable in CI will certainly make everything that bit smoother. Thanks, Ben Shillito Developer O: +44 1183 287152 E: b...@51degrees.com T: @51Degrees

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-12 Thread Dave Chiluk
I did a bit more introspection on our TIME_WAIT connections. The increase in sockets in TIME_WAIT is definitely from old connections to our backend server instances. Considering the fact that this server is doesn't actually serve real traffic we can make a reasonable assumptions that this is

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Willy Tarreau
On Wed, Jun 12, 2019 at 02:49:37PM +, Ben Shillito wrote: > While I was working on the HTX changes, I thought it was probably a good time > to also implement the dummy library as I had my brain in 'HAProxy mode'. Ah, excellent, thank you : $./haproxy -vv|grep -i 51d Feature list : +EPOLL

Re: Idea + question regarding the build targets

2019-06-12 Thread Olivier D
Hi, Le mer. 12 juin 2019 à 19:19, Willy Tarreau a écrit : > Hi guys, > > On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lukas Tribus wrote: > (...) > > I think it's a bad idea. > > > > Basically what Tim says (I was interrupted several times while writing > > this email). > > OK, and this morning

Re: Idea + question regarding the build targets

2019-06-12 Thread Willy Tarreau
Hi guys, On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lukas Tribus wrote: (...) > I think it's a bad idea. > > Basically what Tim says (I was interrupted several times while writing > this email). OK, and this morning William told me he thought the same for the same reasons, so definitely I'm the

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Ben Shillito
Hi Willy, This unfortunately fell down our list of priorities in the last few weeks. However, as this is a bit more urgent now with your weekend release, I will get the change for HTX awareness to you either today or tomorrow if that is ok with you? Thanks, Ben Shillito Developer O: +44 1183

Re: Idea + question regarding the build targets

2019-06-12 Thread Lukas Tribus
Hello Willy, On Wed, 12 Jun 2019 at 07:39, Willy Tarreau wrote: > > Hi all, > > I'm currently re-reading my notes for the upcoming release and found > something I noted not that long ago regarding the TARGET variable of > the makefile. The list of operating systems hasn't changed in a while >

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-12 Thread Ben Shillito
Hi Willy, No worries, that's fine. While I was working on the HTX changes, I thought it was probably a good time to also implement the dummy library as I had my brain in 'HAProxy mode'. Both patches are attached ready to be merged. If there is anything missing, let me know and can I'll try to

Re: [PATCH] BUILD: Silence gcc warning about unused return value

2019-06-12 Thread Vincent Bernat
❦ 12 juin 2019 20:47 +02, Tim Duesterhus : > - write(2, trash.area, trash.data); > + shut_your_big_mouth_gcc(write(2, trash.area, trash.data)); An alternative not discussed in 89efaed6b67b (which introduced this function) is to use "(void)!": (void)!write(2, trash.area, trash.data);

[PATCH 1/1] BUG/MEDIUM: compression: Set Vary: Accept-Encoding if the response would be compressed

2019-06-12 Thread Tim Duesterhus
Make HAProxy set the `Vary: Accept-Encoding` response header if the server response would normally be compressed based off the current configuration. Specifically make sure to: 1. Disregard the *request* headers ... 2. Disregard the current compression rate and other temporary conditions ... ...

[PATCH 0/1] compression: Set Vary: Accept-Encoding

2019-06-12 Thread Tim Duesterhus
Willy, First things first: Yes, I'm aware that this is shortly before 2.0. Either put this into 2.0 or put this into `next` if you consider it too risky (or just wait until 2.0 release before merging). Also *add backporting instructions*, please. I recommend to backport it to 2.0 at the least.

[PATCH v2 1/1] BUG/MEDIUM: compression: Set Vary: Accept-Encoding if the response would be compressed

2019-06-12 Thread Tim Duesterhus
Willy, read the cover letter of this thread before ignoring the first patch, just because this one has a higher version number to avoid mistakes. Apply with `git am --scissors` to automatically cut the commit message. -- >8 -- Make HAProxy set the `Vary: Accept-Encoding` response header if the

[PATCH] BUILD: Silence gcc warning about unused return value

2019-06-12 Thread Tim Duesterhus
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. complains: > src/debug.c: In function

Re: [PATCH] BUG/MINOR: checks: Include UNIX server paths in arguments

2019-06-12 Thread linuxdaemon Snoonet
Hi Willy, Do you think we should abstract the formatting of the address to a function and use the same format for the proxy address for external checks? Currently my changes just mimic the proxy address logic for server address, so if we want to add the ability to easily distinguish the socket