> Le 27 nov. 2017 à 17:52, Olivier Houchard <ohouch...@haproxy.com> a écrit : > > Hi Emmanuel, > > On Mon, Nov 27, 2017 at 05:17:54PM +0100, Emmanuel Hocdet wrote: >> >> Hi, >> >> This patch fix CO_FL_EARLY_DATA removal to have correct ssl_fc_has_early >> reporting. It work for 'mode http'. >> >> It does not fix ssl_fc_has_early for 'mode tcp'. In this mode >> CO_FL_EARLY_DATA >> should not be removed if early data was accepted. >> It is possible to check MODE_TCP in mux_pt_recv? Or there is another way of >> address this? >> >
Hi Olivier, > The first patch seems fine. > The second breaks wait-for-handshake for me, I guess because recv() is called In my tests, wake remove the flag before recv (and ssl_fc_has_early call) > before wake(), and so the flag is removed before that code in > stream_interface.c : > /* If we had early data, and the handshake ended, then > * we can remove the flag, and attempt to wake the task up, > * in the event there's an analyser waiting for the end of > * the handshake. > */ > if ((conn->flags & (CO_FL_EARLY_DATA | CO_FL_EARLY_SSL_HS)) == > CO_FL_EARLY_DATA) { > task_wakeup(si_task(si), TASK_WOKEN_MSG); > } > So the stream task is never woken up. > Maybe the best is to add a new flag per conn_stream, CS_FL_WAITING_FOR_HS or > something, instead of relying on CO_FL_EARLY_DATA. > I think I'm going to do something like that. I think it's a good idea, two different things to deal with one tag. > That still doesn't help with your problem with TCP mode, though. I still want > the CO_FL_EARLY_DATA to be removed after the handshake, so that we don't > add the "Early-Data: 1" header if it is not needed. But it just occured > to me that I can easily fix that by adding the header, not only if > CO_FL_EARLY_DATA is set, but if CO_FL_EARLY_SSL_HS or CO_FL_SSL_WAIT_HS is > set. > That way we will both be happy :) Indeed :) Thanks! Manu