thank you very much for your time on this. I'm adding here some extra
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.
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
> > this problem with 1.7 or not ? The random speed at which data arrive in
> > 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.