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/[email protected]/msg32959.html that test case also returns 400 error with state CH-- with http2. -Jarno > -----Ursprüngliche Nachricht----- > Von: Jarno Huuskonen <[email protected]> > Gesendet: Dienstag, 19. März 2019 17:34 > An: Maximilian Böhm <[email protected]> > Cc: [email protected] > 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 > > "<html><body><h1>400 Bad request</h1>Your browser sent an invalid > > request.</body></html>". 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
