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 <[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 -Jarno -- Jarno Huuskonen
smime.p7s
Description: S/MIME cryptographic signature
