> Yep. For what it's worth, it's been enabled for about one month on
> haproxy.org and till now we didn't get any bad report, which is pretty
> encouraging.
Can I ask where? The negotiated protocol I get on https://haproxy.org/ is
http/1.1 in both Google Chrome and Firefox as an example.
If I
Hi William,
On Thu, Dec 28, 2017 at 09:17:28PM +0100, William Lallemand wrote:
> On Thu, Dec 28, 2017 at 12:54:27AM +0100, William Lallemand wrote:
> > I think that's better to open /dev/null and dup2 with 0, 1, 2 so we won't
> > have any
> > surprise with an fprintf(stderr, ".. anywhere in the
On Fri, Dec 29, 2017 at 08:46:18AM +, Lucas Rolff wrote:
> > Yep. For what it's worth, it's been enabled for about one month on
> > haproxy.org and till now we didn't get any bad report, which is pretty
> > encouraging.
>
> Can I ask where? The negotiated protocol I get on https://haproxy.or
Hello,
On Fri, Dec 29, 2017 at 8:13 AM, Willy Tarreau wrote:
> Yep. For what it's worth, it's been enabled for about one month on haproxy.org
> and till now we didn't get any bad report, which is pretty encouraging.
It appears to run 1.7.5 though:
http://demo.haproxy.org/
>> For now, I'll p
On Fri, Dec 29, 2017 at 11:22:56AM +0100, Lukas Tribus wrote:
> Hello,
>
>
> On Fri, Dec 29, 2017 at 8:13 AM, Willy Tarreau wrote:
> > Yep. For what it's worth, it's been enabled for about one month on
> > haproxy.org
> > and till now we didn't get any bad report, which is pretty encouraging.
>
> Actually that's not the case and that may explain the situation. The machine
> runs OpenSSL 1.0.1 so only NPN is used, ALPN isn't. I'll try with a static
> build of openssl 1.0.2 to see if the ratio increases.
That might very well be the case, I know for sure that Chrome dropped support
NPN a
On Fri, Dec 29, 2017 at 10:46:40AM +0100, Willy Tarreau wrote:
> Hi William,
>
> In fact it still doesn't fclose() the streams, which worries me a little bit
> for the long term, because eventhough any printf() will end up being written
> into /dev/null, it's still preferable to mark the FILE* as
Hello,
On Fri, Dec 29, 2017 at 11:22 AM, Lukas Tribus wrote:
> It's that:
> - when sending the POST request to the backend server, haproxy sends a
> FIN before the server responds
> - nginx doesn't like that and closes the request (you will see nginx
> error code 499 in nginx server logs)
> - as
> Lucas, can you check my previous mail and see if you can enable ignoring
> client aborts in your backend, assuming you are using nginx?
I can confirm that ignoring client aborts in my backend using
fastcgi_ignore_client_abort “resolves” the issue regarding POST requests.
Best Regards,
Lucas R
Hi Lukas,
On Fri, Dec 29, 2017 at 11:45:55AM +0100, Lukas Tribus wrote:
> On Fri, Dec 29, 2017 at 11:22 AM, Lukas Tribus wrote:
> > It's that:
> > - when sending the POST request to the backend server, haproxy sends a
> > FIN before the server responds
> > - nginx doesn't like that and closes the
On Fri, Dec 29, 2017 at 11:45:55AM +0100, Lukas Tribus wrote:
> The FIN behavior comes from a48c141f4 ("BUG/MAJOR: connection: refine
> the situations where we don't send shutw()"), which also hit 1.8.2, so
> that explains the change in behavior between 1.8.1 and 1.8.2.
For me it happens only when
Hello,
I would like to ask about new feature in haproxy 1.8:
check-sni
Please give me some example how I can use this.
I have two servers and I want to check them using SNI.
--
Regards,
*Mariusz Kalota*
Hello,
On Fri, Dec 29, 2017 at 2:31 PM, Willy Tarreau wrote:
> On Fri, Dec 29, 2017 at 11:45:55AM +0100, Lukas Tribus wrote:
>> The FIN behavior comes from a48c141f4 ("BUG/MAJOR: connection: refine
>> the situations where we don't send shutw()"), which also hit 1.8.2, so
>> that explains the ch
Hello,
On Fri, Dec 29, 2017 at 2:45 PM, Mariusz Kalota wrote:
> Hello,
> I would like to ask about new feature in haproxy 1.8:
> check-sni
>
> Please give me some example how I can use this.
It's as simple as:
check-sni
So a backend would look like this for example:
backend secure_wwwfarm
s
On Fri, Dec 29, 2017 at 02:52:39PM +0100, Lukas Tribus wrote:
> > For me it happens only when I have "option httpclose" in the configuration,
> > ie we end up in tunnel mode. I can't reproduce it with either keep-alive,
> > http-server-close nor forceclose. At least abortonclose is now safe
> > reg
W dniu 2017-12-29 o 14:56, Lukas Tribus pisze:
> Hello,
>
>
> On Fri, Dec 29, 2017 at 2:45 PM, Mariusz Kalota wrote:
>> Hello,
>> I would like to ask about new feature in haproxy 1.8:
>> check-sni
>>
>> Please give me some example how I can use this.
> It's as simple as:
> check-sni
>
> So a back
Hello,
On Fri, Dec 29, 2017 at 3:06 PM, Mariusz Kalota wrote:
> I have two serwers. Servers need client certificate to give answer. My
> configuration is like this:
>
> listen https-test-5
> bind *:5
> mode tcp
> balance roundrobin
> option httpchk GET /somefile.asmx
> server server1 19
W dniu 2017-12-29 o 15:14, Lukas Tribus pisze:
> Hello,
>
>
>
> On Fri, Dec 29, 2017 at 3:06 PM, Mariusz Kalota wrote:
>> I have two serwers. Servers need client certificate to give answer. My
>> configuration is like this:
>>
>> listen https-test-5
>> bind *:5
>> mode tcp
>> balance roun
Hello,
On Fri, Dec 29, 2017 at 3:05 PM, Willy Tarreau wrote:
>> Haproxy calls shutdown() after the HTTP payload was transmitted, nginx
>> in the default configuration or nc for that matter closes the
>> connection (we see recvfrom = 0) and then we close():
>
> I can't reproduce this one for now.
Hello,
On Fri, Dec 29, 2017 at 3:24 PM, Mariusz Kalota wrote:
> Hello, thanks for reply.
>
> I would like to forward the encrypted HTTPS transparently to the
> backend. I would like to check health my backend servers, but not only
> on layer 4, but on layer 7. So I have to get /somefile.asmx, an
On Fri, Dec 29, 2017 at 03:26:44PM +0100, Lukas Tribus wrote:
> Indeed when the frontend connection is H1, a single send() call
> contains both headers and payload and the issue does not occur. But
> when the frontend connection is H2, then header and payload are in 2
> distinct send calls and the
On Fri, Dec 29, 2017 at 03:30:41PM +0100, Willy Tarreau wrote:
> On Fri, Dec 29, 2017 at 03:26:44PM +0100, Lukas Tribus wrote:
> > Indeed when the frontend connection is H1, a single send() call
> > contains both headers and payload and the issue does not occur. But
> > when the frontend connection
W dniu 2017-12-29 o 15:28, Lukas Tribus pisze:
> Hello,
>
>
> On Fri, Dec 29, 2017 at 3:24 PM, Mariusz Kalota wrote:
>> Hello, thanks for reply.
>>
>> I would like to forward the encrypted HTTPS transparently to the
>> backend. I would like to check health my backend servers, but not only
>> on l
On Fri, Dec 29, 2017 at 03:42:30PM +0100, Willy Tarreau wrote:
> OK I managed to reproduce it with nghttp using --expect-continue to
> force it to leave a pause before sending the data. And indeed there
> the data are immediately followed by a shutdown. Getting closer...
So here's what I found : w
W dniu 2017-12-29 o 15:53, Mariusz Kalota pisze:
> W dniu 2017-12-29 o 15:28, Lukas Tribus pisze:
>> Hello,
>>
>>
>> On Fri, Dec 29, 2017 at 3:24 PM, Mariusz Kalota wrote:
>>> Hello, thanks for reply.
>>>
>>> I would like to forward the encrypted HTTPS transparently to the
>>> backend. I would li
W dniu 2017-12-29 o 16:10, Mariusz Kalota pisze:
> W dniu 2017-12-29 o 15:53, Mariusz Kalota pisze:
>> W dniu 2017-12-29 o 15:28, Lukas Tribus pisze:
>>> Hello,
>>>
>>>
>>> On Fri, Dec 29, 2017 at 3:24 PM, Mariusz Kalota wrote:
Hello, thanks for reply.
I would like to forward the en
Hi William, Willy,
Op 29-12-2017 om 11:35 schreef William Lallemand:
On Fri, Dec 29, 2017 at 10:46:40AM +0100, Willy Tarreau wrote:
Hi William,
In fact it still doesn't fclose() the streams, which worries me a little bit
for the long term, because eventhough any printf() will end up being writ
Hi Pieter,
On Fri, Dec 29, 2017 at 04:19:21PM +0100, PiBa-NL wrote:
> Op 29-12-2017 om 11:35 schreef William Lallemand:
> > On Fri, Dec 29, 2017 at 10:46:40AM +0100, Willy Tarreau wrote:
> > > Hi William,
> > >
> > > In fact it still doesn't fclose() the streams, which worries me a little
> > >
On Fri, Dec 29, 2017 at 11:35:10AM +0100, William Lallemand wrote:
> On Fri, Dec 29, 2017 at 10:46:40AM +0100, Willy Tarreau wrote:
> > Hi William,
> >
> > In fact it still doesn't fclose() the streams, which worries me a little bit
> > for the long term, because eventhough any printf() will end u
Both in Firefox and Chrome my POST requests in 1.8.2 with the supplied patch,
seem to do the trick (did about 300 post requests in each browser with no
fails).
Best Regards,
On 29/12/2017, 15.58, "Willy Tarreau" wrote:
On Fri, Dec 29, 2017 at 03:42:30PM +0100, Willy Tarreau wrote:
> O
Hi Willy,
On Fri, Dec 29, 2017 at 3:58 PM, Willy Tarreau wrote:
> On Fri, Dec 29, 2017 at 03:42:30PM +0100, Willy Tarreau wrote:
>> OK I managed to reproduce it with nghttp using --expect-continue to
>> force it to leave a pause before sending the data. And indeed there
>> the data are immediate
Hello Mariusz,
On Fri, Dec 29, 2017 at 4:17 PM, Mariusz Kalota wrote:
> Ok. I fixed it.
> My currently working config:
>
> listen https-test-5
> bind *:5
> mode tcp
> balance roundrobin
> option httpchk GET /somefile.asmx HTTP/1.1\r\nHost test.site.local:5
> server server1 192.168.0
On Fri, Dec 29, 2017 at 04:46:57PM +0100, Lukas Tribus wrote:
> On Fri, Dec 29, 2017 at 3:58 PM, Willy Tarreau wrote:
> > On Fri, Dec 29, 2017 at 03:42:30PM +0100, Willy Tarreau wrote:
> >> OK I managed to reproduce it with nghttp using --expect-continue to
> >> force it to leave a pause before se
> Lucas, Maximilian, can you check the situation with this patch? The POST
> issue should definitely be gone, please also verify the GET issue with this
> patch (as I was unable to reproduce it).
Sadly didn’t fix the GET request issue for me in Firefox:
https://snaps.hcdn.dk/h1Oz3G950oepEb30AEo
On Fri, Dec 29, 2017 at 04:10:12PM +, Lucas Rolff wrote:
> > Lucas, Maximilian, can you check the situation with this patch? The POST
> > issue should definitely be gone, please also verify the GET issue with this
> > patch (as I was unable to reproduce it).
>
> Sadly didn't fix the GET requ
> If you're willing to run another test, I can prepare a debugging patch which
> will try to report every single error path in the H2 and HPACK code so that
> we can try to understand where the code was upset
I’d love to run another test or 10 – in the end, we’ll all benefit from it
(hopefully)
Hi Davor,
Ah now at least I have something I can disagree with :-)
First, in the future, please cut such changes into multiple patches. It's
fine to have a large patch to fix typos and formatting, but it's a real
pain to also have content changes to review in the same patch, as comments
may come
On Fri, Dec 29, 2017 at 04:48:13PM +, Lucas Rolff wrote:
> > If you're willing to run another test, I can prepare a debugging patch
> > which will try to report every single error path in the H2 and HPACK code
> > so that we can try to understand where the code was upset
>
> I'd love to run
unsubscribe
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
I'm a bit befuddled by the different nameserver config 'twixt these 2 modes?
[ Methinks I grok the need for an internal non-libc/libresolv resolver ]
Why isn't the the /etc/resolv.conf start-time config used (or at least
available) as a default run-time config (chroot notwithstanding)?
Under what
Working page load (total of 4 requests), and we see 4x 3180|3067
POST Request (to website):
h2s_frt_make_resp_data:3180
h2s_frt_make_resp_data:3067
-
GET Request (to website):
h2s_frt_make_resp_data:3180
h2s_frt_make_resp_data:3067
-
GET Request (app.css)
h2s_frt_make_resp_data:3180
h2s_frt_make_r
On Fri, Dec 29, 2017 at 06:02:15PM +, Lucas Rolff wrote:
> POST Request (to website):
> h2s_frt_make_resp_data:3180
> h2s_frt_make_resp_data:3067
> -
> GET Request (to website):
> h2s_frt_make_resp_data:3180
> h2s_frt_make_resp_data:3067
> -
> Get Request (app.css)
> h2_frt_decode_headers:2621
I think you forgot to attach the patch
I did try to add the continue patch for the “blacklisted” headers, and same
result (now in this case, it happened on the website request itself:
POST Request to site:
h2s_frt_make_resp_data:3180
h2s_frt_make_resp_data:3067
GET Request to site:
h2_frt_decod
On Fri, Dec 29, 2017 at 06:18:00PM +, Lucas Rolff wrote:
> I think you forgot to attach the patch
Grrr common mistake, sorry.
> I did try to add the continue patch for the "blacklisted" headers, and same
> result (now in this case, it happened on the website request itself:
Thanks, I'll tak
h2_make_h1_request:153
h2_frt_decode_headers:2621
h2_frt_decode_headers:2643
/* this can be any type of header */
/* RFC7540#8.1.2: upper case not allowed in header field names */
for (i = 0; i < list[idx].n.len; i++)
if ((uint8_t)(list[idx].n.ptr[i] - 'A') < 'Z' - 'A')
got
On Fri, Dec 29, 2017 at 06:56:36PM +, Lucas Rolff wrote:
> h2_make_h1_request:153
> h2_frt_decode_headers:2621
> h2_frt_decode_headers:2643
>
> /* this can be any type of header */
> /* RFC7540#8.1.2: upper case not allowed in header field names */
> for (i = 0; i < list[idx].n.len; i++)
>
Hello,
On Fri, Dec 29, 2017 at 7:00 PM, Jim Freeman wrote:
> I'm a bit befuddled by the different nameserver config 'twixt these 2 modes?
> [ Methinks I grok the need for an internal non-libc/libresolv resolver ]
>
> Why isn't the the /etc/resolv.conf start-time config used (or at least
> availa
Great feedback - thanks !
I'll take a look at the code ...
On Fri, Dec 29, 2017 at 12:59 PM, Lukas Tribus wrote:
> Hello,
>
>
> On Fri, Dec 29, 2017 at 7:00 PM, Jim Freeman wrote:
> > I'm a bit befuddled by the different nameserver config 'twixt these 2
> modes?
> > [ Methinks I grok the need
On Fri, Dec 29, 2017 at 06:56:36PM +, Lucas Rolff wrote:
> h2_make_h1_request:153
> h2_frt_decode_headers:2621
> h2_frt_decode_headers:2643
>
> /* this can be any type of header */
> /* RFC7540#8.1.2: upper case not allowed in header field names */
> for (i = 0; i < list[idx].n.len; i++)
>
<<
:authority: dashboard.domain.com
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0)
Gecko/20100101 Firefox/59.0
accept: text/css,*/*;q=0.1
accept-language: da,en-US;q=0.8,en;q=0.6,es;q=0.4,tr;q=0.2
accept-encoding: gzip, deflate, br
referer: https://dashboard.dom
On Fri, Dec 29, 2017 at 08:45:57PM +, Lucas Rolff wrote:
> So, this Wx1ZSI usually should be "cookie" - however it's somehow turned into
> garbage.
Ah, this is what I was wondering.
> Repeated - now it's s3U2JV - but still supposed to be "cookie":
Great, so the number of characters is correc
Looks like libresolv 's res_ninit() parses out /etc/resolv.conf 's
nameservers [resolv.h], so haproxy won't have to parse it either ...
Will keep poking.
On Fri, Dec 29, 2017 at 12:59 PM, Lukas Tribus wrote:
> Hello,
>
>
> On Fri, Dec 29, 2017 at 7:00 PM, Jim Freeman wrote:
> > I'm a bit bef
Hi Jim,
On Fri, Dec 29, 2017 at 10:14 PM, Jim Freeman wrote:
> Looks like libresolv 's res_ninit() parses out /etc/resolv.conf 's
> nameservers [resolv.h], so haproxy won't have to parse it either ...
>
> Will keep poking.
Do give it some time to discuss the implementation here first though,
be
Hello Jim.
I've seen the thread and that you're "befuddled" a little about the use of DNS.,
Think of it this way, with the resolvers in HAProxy you can resolve
the real server names of real server pool, this may be very dynamic in
nature and separate to /etc/resolve.conf
Now imagine a farm of Ha
I'm not proposing use of /etc/resolv.conf *instead* of haproxy's other
configs, only as *a* (default) config [the same default that is good enough
for haproxy to use at start-time].
So if that config suffices (as I suspect it usually does), config is
simplified.
Attached is a trivial program that
Hello Willy,
regarding soft-stop H2 behavior, we may have room for improvement.
We often have "timeout client" (H2) in the 30 - 60 seconds range,
while "timeout http-keep-alive" (H1) may only be a few seconds (or
less). When we soft-stop a process we add "Connection: close" to all
H1 responses
Hi Lukas,
On Fri, Dec 29, 2017 at 11:28:42PM +0100, Lukas Tribus wrote:
> Hello Willy,
>
>
> regarding soft-stop H2 behavior, we may have room for improvement.
A polite way to say I did some crap ;-)
> We often have "timeout client" (H2) in the 30 - 60 seconds range,
> while "timeout http-keep
57 matches
Mail list logo
