ABV: Re- Confirmation FILE1042/2019.

2019-03-20 Thread Felix Brandon
 - This mail is in HTML. Some elements may be ommited in plain text. -

Hello,
The CBD Bank had earlier sent you an email notification since on the 2nd of 
March 2019 and are yet to receive any feedback from you. This is very important 
and an urgent information that might be of great interest to you.
I have been directed to send you a follow up of our initial correspondence 
incase you did not get our previous email.
Kindly confirm that you got my message so I can resend you the proper 
information.
I await for your response via my personal email:
branfel...@gmail.com
Sincere regards,
Felix Brandon.
CBD BANK UAE.
www.cbd.ae
Disclaimer:
This Electronic Mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you are not an addressee, or have received the message by error, 
please notify the sender via E-Mail or over the telephone and delete this 
e-mail.  You are not authorized to read, copy, disseminate, distribute or use 
this E-Mail or any of its attachment in any way.  Any views or opinions 
presented in this email are solely those of the author.


Re: 400 SC on h2 xhr post

2019-03-20 Thread Jarno Huuskonen
Hi Max,

On Wed, Mar 20, Maximilian Böhm wrote:
> >> If the 400 errors happen within 3mins, have you tried changing 
> >> client/keep-alive timeouts to see if anything changes ?
> They do most often happen in the first 3 mins. But that's not always the 
> case. And if it's really a timeout, shouldn't it be more clearly recurring? 
> Like every tenth request fails. But that's also not the case. Sometimes it's 
> the 3rd request, sometimes the 20th or even later.
> However, I did increase the previously set timeouts (40min). But this did not 
> change anything at all. Is there another timeout which explicitly only 
> affects h2 on the client side?

I'm not aware of any more timeouts to test. I think possible timeouts
are in https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4.1

Have you tested different values for http-reuse (never to always) ?
(https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4.2-http-reuse)
(Probably doesn't make any difference).

This could be related to 
https://www.mail-archive.com/haproxy@formilux.org/msg32959.html
that test case also returns 400 error with state CH-- with http2.

-Jarno

> -Ursprüngliche Nachricht-
> Von: Jarno Huuskonen  
> Gesendet: Dienstag, 19. März 2019 17:34
> An: Maximilian Böhm 
> Cc: haproxy@formilux.org
> Betreff: Re: 400 SC on h2 xhr post
> 
> Hi,
> 
> On Tue, Mar 19, Maximilian Böhm wrote:
> > The problem I experience is within a legacy javascript application which 
> > periodically checks if the user is still logged in. It does so by sending 
> > an xhr request every 30 seconds (I said, it's a legacy app, right? It does 
> > so by POST not GET...). As you may guess, this behavior works using http1.1 
> > quasi infinitely. But as soon as I activate HTTP/2, I'll get the following 
> > output (sooner or later): 
> > 172.17.0.1:46372 [19/Mar/2019:12:10:13.465] [fntnd] [bknd] 0/0/0/14/14 200 
> > 368 - -  1/1/0/1/0 0/0 "POST   [URL] HTTP/1.1"
> > 172.17.0.1:46372 [19/Mar/2019:12:10:43.465] [fntnd] [bknd] 0/0/0/-1/8 400 
> > 187 - - CH-- 1/1/0/0/0 0/0 "POST [URL] HTTP/1.1"
> > 
> > Which means, the developer toolbar announces a response code "400" and 
> > "400 Bad requestYour browser sent an invalid 
> > request.". I was not yet successful reproduce this behavior 
> > with OkHttp (java http2-capable library). Jetty - on the backend site - 
> > does not report any requests in its ncsa request log.
> 
> I've seen some(very few (maybe one-two a day)) 400 bad requests with haproxy 
> 1.9.4 (http2) to apache+php (http/1.1) backend. These requests alos have CH.. 
> state in logs.
> (400 errors have also happened for GET requests).
> 
> > It is not directly reproducible (like every second time) but it usually 
> > happens with the first 3 minutes. I experienced this behavior in Chrome 
> > (73.0.3683.75), Firefox (65.0.2 (32-Bit)) and Edge (44.17763.1.0). I also 
> > tried with different networks and different internet connections.
> > 
> > Any ideas? Maybe a similar bug is known? What shall/can I do next? Setting 
> > up Wireshark with MITM and comparing the requests? Right now, I can't 
> > imagine the error is on side of the client nor on the backend (the backend 
> > is not changed). 
> 
> If the 400 errors happen within 3mins, have you tried changing 
> client/keep-alive timeouts to see if anything changes ?
> 
> > timeout queue   2m
> > timeout client  2m
> > timeout http-keep-alive 2m



AW: 400 SC on h2 xhr post

2019-03-20 Thread Maximilian Böhm
Hello Jarno,

>> If the 400 errors happen within 3mins, have you tried changing 
>> client/keep-alive timeouts to see if anything changes ?
They do most often happen in the first 3 mins. But that's not always the case. 
And if it's really a timeout, shouldn't it be more clearly recurring? Like 
every tenth request fails. But that's also not the case. Sometimes it's the 3rd 
request, sometimes the 20th or even later.
However, I did increase the previously set timeouts (40min). But this did not 
change anything at all. Is there another timeout which explicitly only affects 
h2 on the client side?

Thanks,
Max

-Ursprüngliche Nachricht-
Von: Jarno Huuskonen 
Gesendet: Dienstag, 19. März 2019 17:34
An: Maximilian Böhm 
Cc: haproxy@formilux.org
Betreff: Re: 400 SC on h2 xhr post

Hi,

On Tue, Mar 19, Maximilian Böhm wrote:
> The problem I experience is within a legacy javascript application which 
> periodically checks if the user is still logged in. It does so by sending an 
> xhr request every 30 seconds (I said, it's a legacy app, right? It does so by 
> POST not GET...). As you may guess, this behavior works using http1.1 quasi 
> infinitely. But as soon as I activate HTTP/2, I'll get the following output 
> (sooner or later):
> 172.17.0.1:46372 [19/Mar/2019:12:10:13.465] [fntnd] [bknd] 0/0/0/14/14 200 
> 368 - -  1/1/0/1/0 0/0 "POST   [URL] HTTP/1.1"
> 172.17.0.1:46372 [19/Mar/2019:12:10:43.465] [fntnd] [bknd] 0/0/0/-1/8 400 187 
> - - CH-- 1/1/0/0/0 0/0 "POST [URL] HTTP/1.1"
>
> Which means, the developer toolbar announces a response code "400" and 
> "400 Bad requestYour browser sent an invalid 
> request.". I was not yet successful reproduce this behavior 
> with OkHttp (java http2-capable library). Jetty - on the backend site - does 
> not report any requests in its ncsa request log.

I've seen some(very few (maybe one-two a day)) 400 bad requests with haproxy 
1.9.4 (http2) to apache+php (http/1.1) backend. These requests alos have CH.. 
state in logs.
(400 errors have also happened for GET requests).

> It is not directly reproducible (like every second time) but it usually 
> happens with the first 3 minutes. I experienced this behavior in Chrome 
> (73.0.3683.75), Firefox (65.0.2 (32-Bit)) and Edge (44.17763.1.0). I also 
> tried with different networks and different internet connections.
>
> Any ideas? Maybe a similar bug is known? What shall/can I do next? Setting up 
> Wireshark with MITM and comparing the requests? Right now, I can't imagine 
> the error is on side of the client nor on the backend (the backend is not 
> changed).

If the 400 errors happen within 3mins, have you tried changing 
client/keep-alive timeouts to see if anything changes ?

> timeout queue   2m
> timeout client  2m
> timeout http-keep-alive 2m

-Jarno

--
Jarno Huuskonen


smime.p7s
Description: S/MIME cryptographic signature