Hello Willy, thank you very much for your time on this. I'm adding here some extra information:
Did you notice this problem with 1.7 or not ? No, I tried with 1.8.1 (required by the system I'm using) and then I moved to last version to try. Downgrading the version would take me some hours due I would have to rebuild the whole system. Could you please check if adding "option http-buffer-request" makes it > worse or better ? Yes! With that option I get 100% success. Also please check in your logs if the faulty requests have experienced any > retry or redispatch. The faulty requests are not being retried or similar, because they don't generate a failure, they just arrive to the login form with a wrong (corrupt) password, so the login fails but the requests are ok. I tried also another thing, related to the content-type of the requests, and maybe could help you troubleshooting. If I sent the requests from the client with the header " *X-Content-Type-Options*" = "*nosniff*", the error is no longer reproduced. I hope this helps, please let me know of you need any extra details or to try more tests. Regards, Roque 2018-02-08 10:22 GMT+01:00 Willy Tarreau <w...@1wt.eu>: > On Thu, Feb 08, 2018 at 09:44:38AM +0100, Willy Tarreau wrote: > > Now I'm seeing it. So it means that we're having something wrong with the > > position computation once data start to come in the buffer. Did you > notice > > this problem with 1.7 or not ? The random speed at which data arrive in > the > > buffer explain the fact that you observe neither 0% nor 100% hit. > > > > Could you please check if adding "option http-buffer-request" makes it > > worse or better ? I guess you'll get either 100% failure or 100% success, > > this will help troubleshooting (and will possibly help you workaround the > > issue for some time). > > By the way, I tried hard but never managed to get it to fail at all, so the > tests above will be useful. Also please check in your logs if the faulty > requests have experienced any retry or redispatch. It's in these cases that > the http-send-name-header gets trickier. And since you're using maxconn 1, > I'm wondering if one reason might not be because the server behind is a bit > limited, possibly causing a significant enough number of retries exhibiting > the bug. > > Thanks, > Willy > -- Roque Porchetto
