Hi Willy, Aleks,
I will try the things suggested this afternoon (hopefully) or tomorrow and get
back to you.
> At least if nginx does this it should send a GOAWAY
> frame indicating that it will stop after stream #2001.
That's my understanding as well (and the docs say as much). I assumed
Hi Luke,
On Mon, Jan 21, 2019 at 09:30:39AM +, Luke Seelenbinder wrote:
> After enabling h2 backends (technically `server ... alpn h2,http/1.1`), we
> began seeing a high number of backend /server/ connection resets. A
> reasonable number of client-side connection resets due to timeouts,
On Tue, Jan 22, 2019 at 09:32:22AM +0100, Lukas Tribus wrote:
> Hello,
>
>
> On Tue, 22 Jan 2019 at 03:04, ??? wrote:
> >
> > Dear willy:
> >
> > I am a follower of haproxy. I tested HTTP/2 fuction in haproxy_1.8.17
> > with the tool h2spec, but some test cases failed. I wonder if those
Hello,
On Tue, 22 Jan 2019 at 03:04, 高和东 wrote:
>
> Dear willy:
>
> I am a follower of haproxy. I tested HTTP/2 fuction in haproxy_1.8.17
> with the tool h2spec, but some test cases failed. I wonder if those are bugs
> for haproxy.
> See the tool here
On Tue, Jan 22, 2019 at 09:42:53AM +, Luke Seelenbinder wrote:
> Hi Willy, Aleks,
>
> I will try the things suggested this afternoon (hopefully) or tomorrow and
> get back to you.
>
> > At least if nginx does this it should send a GOAWAY
> > frame indicating that it will stop after stream
> Le 21 janv. 2019 à 19:07, Dirkjan Bussink a écrit :
>
> Hi Manu,
>
>> On 21 Jan 2019, at 09:49, Emmanuel Hocdet wrote:
>>
>> Boringssl does not have SSL_OP_NO_RENEGOTIATION and need KeyUpdate to work.
>> As workaround, SSL_OP_NO_RENEGOTIATION could be set to 0 in openssl-compat.h.
>
>
Hi Willy,
On 1/21/19 6:38 PM, Dirkjan Bussink wrote:
> Hi Emeric,
>
>> On 21 Jan 2019, at 08:06, Emeric Brun wrote:
>>
>> Interesting, it would be good to skip the check using the same method.
>>
>> We must stay careful to not put the OP_NO_RENEG flag on the client part
>> (when haproxy
Hi Willy,
On 1/21/19 6:38 PM, Dirkjan Bussink wrote:
> Hi Emeric,
>
>> On 21 Jan 2019, at 08:06, Emeric Brun wrote:
>>
>> Interesting, it would be good to skip the check using the same method.
>>
>> We must stay careful to not put the OP_NO_RENEG flag on the client part
>> (when haproxy
> Le 21 janv. 2019 à 19:31, Adam Langley a écrit :
>
> On Mon, Jan 21, 2019 at 10:16 AM Dirkjan Bussink wrote:
>> Ah ok, I recently added support in HAProxy to handle the new
>> SSL_CTX_set_ciphersuites option since OpenSSL handles setting TLS 1.3
>> ciphers separate from the regular ones.
Tim.
Am 22.01.2019 um 20:57 schrieb Tim Düsterhus:
> Aleks,
>
> Am 22.01.19 um 20:50 schrieb Aleksandar Lazic:
>> This means that the function in haproxy works but the check should be
>> adopted to
>> match both cases, right?
>
> At least one should investigate what exactly is happening here
On Tue, Jan 22, 2019 at 11:45 AM Aleksandar Lazic wrote:
> Can it be reused to test a specific server like?
>
> ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443
Not easily: it drives the implementation under test by forking a
process and has quite a complex interface via
Am 22.01.2019 um 20:54 schrieb Adam Langley:
> On Tue, Jan 22, 2019 at 11:45 AM Aleksandar Lazic wrote:
>> Can it be reused to test a specific server like?
>>
>> ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443
>
> Not easily: it drives the implementation under test by forking a
On Tue, Jan 22, 2019 at 12:13 PM Aleksandar Lazic wrote:
> Sorry for my dump question, I just want to be save not to break something.
>
> It would be nice to have the option '-key-update' in client.cc and server.cc
> where can I put this feature request for boringssl?
>
> That would be make the
Hi Aleksandar,
Just FYI.
Op 22-1-2019 om 22:08 schreef Aleksandar Lazic:
But this could be a know bug and is fixed in the current git
-
## Starting vtest ##
Testing with haproxy version: 1.9.2
#top TEST
Am 22.01.2019 um 21:45 schrieb Adam Langley:
> On Tue, Jan 22, 2019 at 12:13 PM Aleksandar Lazic wrote:
>> Sorry for my dump question, I just want to be save not to break something.
>>
>> It would be nice to have the option '-key-update' in client.cc and server.cc
>> where can I put this feature
Aleks,
Am 22.01.19 um 20:50 schrieb Aleksandar Lazic:
> This means that the function in haproxy works but the check should be adopted
> to
> match both cases, right?
At least one should investigate what exactly is happening here (the
differences between the libc is a guess) and possibly file a
Hi Christopher,
I can confirm the patches fixed the issue. Thanks again for fixing this up!
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com
‐‐‐ Original Message ‐‐‐
On Monday, January 21, 2019 2:07 PM, Christopher Faulet
wrote:
> Le 18/01/2019 à 14:23, Luke
Hi Willy,
I just confirmed the other patchset works, so I will start going down this
road. :-)
While testing the other issue, I discovered something fascinating. Our
application is typically used by clients that cancel requests with reasonable
frequency (5+%). When zooming in and out of maps
Hi guys,
On Tue, Jan 22, 2019 at 03:22:38PM +0100, Emeric Brun wrote:
> I think you can merge this.
OK. I still find it very fragile in that we usually don't make a
difference between an absent define and the same declared as zero, and
most SSL_OP_* entries are defined this way in ssl_sock.c,
On Tue, Jan 22, 2019 at 02:57:23PM +, Luke Seelenbinder wrote:
> There is a strong correlation between client connections canceling requests
> (resulting in a HTTP log string of CD--) and then a whole string of requests
> immediately after resulting in server connection resets (resulting in
Hi Dirkjan,
On Tue, Jan 22, 2019 at 11:07:07PM -0800, Dirkjan Bussink wrote:
> I have adjusted the patch to make it more robust and more match the style of
> how we use other options. How does this look to you?
Unfortunately it does introduce the problem I feared for BoringSSL :
+#if
Hi Luke,
I've place an nginx instance after my local haproxy dev config, and
found something which might explain what you're observing : the process
apparently leaks FDs and fails once in a while, causing 500 to be returned :
2019/01/23 08:22:13 [crit] 25508#0: *36705 open()
Hi Willy,
> On 22 Jan 2019, at 07:07, Willy Tarreau wrote:
>
> Hi guys,
>
> On Tue, Jan 22, 2019 at 03:22:38PM +0100, Emeric Brun wrote:
>> I think you can merge this.
>
> OK. I still find it very fragile in that we usually don't make a
> difference between an absent define and the same
Am 22.01.2019 um 19:54 schrieb Aleksandar Lazic:
> Cool, thanks.
>
> Do have boringssl a similar tool like s_client?
>
> I don't like to build openssl just for s_client call :-)
Answer my own question.
bssl is the boringssl tool command.
The open question is why the tests fails in container?
Aleks,
Am 22.01.19 um 19:38 schrieb Aleksandar Lazic:
> ## test results in:
> "/tmp/haregtests-2019-01-22_18-28-24.aBghMD/vtc.3398.76167f9e"
> s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) ==
> "2001:db8:c001:c01a:0::10:0" failed
The difference here is that the
Am 22.01.2019 um 20:30 schrieb Adam Langley:
> On Tue, Jan 22, 2019 at 11:16 AM Aleksandar Lazic wrote:
>> Agree that I get a 400 with this command.
>>
>> `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443`
>
> (Note that "K" on its own line does not send a KeyUpdate message with
>
On Tue, Jan 22, 2019 at 11:16 AM Aleksandar Lazic wrote:
> Agree that I get a 400 with this command.
>
> `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443`
(Note that "K" on its own line does not send a KeyUpdate message with
BoringSSL's bssl tool. It just sends "K\n".)
> How does
Hello Joao Guimaraes,
The following lines should accomplish what you described in your email:
acl is_main_site hdr(Host) -i www.mysite.com mysite.com
http-request set-var(req.scheme) str(https) if { ssl_fc }
http-request set-var(req.scheme) str(http) if !{ ssl_fc }
Hi Aleksandar,
Thanks for your tips.
> Do you have such a info in the nginx log?
>
> "http2 flood detected"
I did not find this in any of the logs from when the buggy configuration was
deployed.
> Can you try to set some timeout values for`timeout http-keep-alive`
I do have this set
Am 21.01.2019 um 23:40 schrieb Joao Guimaraes:
> Hi Haproxy team!
>
> I've been trying to figure out how to perform automatic redirects based on
> source URL transformations.
>
> *Basically I need the following redirect: *
>
> mysite.*abc* redirected to *abc*.mysite.com .
Maybe you can
wt., 22 sty 2019 o 19:40 Aleksandar Lazic napisał(a):
>
> Hi.
>
> I have now build haproxy with boringssl and it looks quite good.
>
> Is it the recommended way to simply make a git clone without any branch or
> tag?
> Does anyone know how the KeyUpdate can be tested?
openssl s_client -connect
Am 22.01.2019 um 20:04 schrieb Adam Langley:
> On Tue, Jan 22, 2019 at 10:54 AM Aleksandar Lazic wrote:
>> Do have boringssl a similar tool like s_client?
>
> BoringSSL builds tool/bssl (in the build directory), which is similar.
> However it doesn't have any magic inputs that can trigger a
Hi.
I have now build haproxy with boringssl and it looks quite good.
Is it the recommended way to simply make a git clone without any branch or tag?
Does anyone know how the KeyUpdate can be tested?
###
HA-Proxy version 1.9.2 2019/01/16 - https://haproxy.org/
Build options :
TARGET =
Cool, thanks.
Do have boringssl a similar tool like s_client?
I don't like to build openssl just for s_client call :-)
Regards
Aleks
Ursprüngliche Nachricht
Von: Janusz Dziemidowicz
Gesendet: 22. Jänner 2019 19:49:15 MEZ
An: Aleksandar Lazic
CC: HAProxy
Betreff: Re:
On Tue, Jan 22, 2019 at 10:54 AM Aleksandar Lazic wrote:
> Do have boringssl a similar tool like s_client?
BoringSSL builds tool/bssl (in the build directory), which is similar.
However it doesn't have any magic inputs that can trigger a KeyUpdate
message like OpenSSL's s_client.
Cheers
AGL
Tim.
Am 22.01.2019 um 20:26 schrieb Tim Düsterhus:
> Aleks,
>
> Am 22.01.19 um 19:38 schrieb Aleksandar Lazic:
>> ## test results in:
>> "/tmp/haregtests-2019-01-22_18-28-24.aBghMD/vtc.3398.76167f9e"
>> s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) ==
>>
36 matches
Mail list logo
