On Wed, Sep 09, 2020 at 05:35:28PM +0200, Willy Tarreau wrote: > On Wed, Sep 09, 2020 at 04:57:58PM +0200, William Dauchy wrote: > > > I think it's not easy to reproduce these tests, you need a high enough > > > latency between haproxy and the client so that the handshake is not > > > already completed when you evaluate the rule, and of course you need > > > to make sure the client sends using early data. I don't remember how > > > Olivier used to run his tests but I remember that it was a bit tricky, > > > so it's very possible that you never fall into the situation where you > > > can see the unvalidated early data yet. > > > > It means my understanding of this fetcher was wrong indeed. > > For me the protection was here: > > http-request wait-for-handshake if ! METH_GET > > and the fetcher here to log whether it was a 0rtt request or not. > > In reality, it means all our requests have completed the handshake > > when the rule is evaluated (which is surprising looking at the number > > we have). > > That seems strange indeed but looking at the code that's what I'm > seeing. Was your access to ssl_fc_has_early placed before or after the > rule above ? If it's after it must indeed report false. > > > So maybe we can possibly work on an alternative fetcher to know > > whether this was a 0rtt request? Or is there another way? > > I seem to remember there was one but can't find it, so I may have been > confused. With this said, it doesn't provide a big information since > once the handshake is completed, it's exactly identical to a regular > one. But it can be nice for statistics at least. >
Pretty sure the original version always returned 1 if there were early data, but we changed it so that it would return 0 once the handshake was done, as we thought it was more useful, that may be what you're thinking about. Olivier
