> > 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.
fetcher is placed before the rule > > 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. Yes I indeed found the commit which changed the behaviour. In fact I probably mixed the true meaning of the definition in the doc and the old blog post about it which is vague. Now everything is clear. >From our point of view, it's interesting to check some behavioural changes we can make on the L4 layer (e.g. hash including source port or not). > That indeed tells me something. However I checked if CO_FL_EARLY_DATA > persists, and apparently we kill it very early once we have everything > so it's not as if we could trivially add a new sample fetch function to > report its past status. > > Also I seem to remember that we concluded that depending on the timing > and how data were aggregated and processed in the SSL lib, we couldn't > reliably report the use of early data if those were converted very early. At some point I was asking myself whether this could be done but simply to give a signal without any guarantee, but you seemed to conclude that it's not reliable enough to become a new fetcher. -- William
