On Mon, Jan 24, 2022 at 2:02 PM Graham Leggett <minf...@sharp.fm> wrote: > > Looks like mod_reqtimeout’s capabilities are overstated at this point - the > module neatly steps out the way and does nothing the moment it sees a non > blocking connection: > > https://github.com/apache/httpd/blob/trunk/modules/filters/mod_reqtimeout.c#L226
Well, this is after check_time_left().. > > I imagine what we need in the async case is to have the ability to override > the timeout on the connection, Which is what mod_reqtimeout does already by applying a "time self" to the socket timeout. > and have the MPM react to that timeout. The pattern would then be set the > timeout and return APR_EAGAIN, let the mpm handle the timeout. Or let the MPM apply the (dynamic-)timeout set on the socket. > > We also need to teach mod_reqtimeout’s code that SSL/TLS libraries sometimes > want to write: > > https://github.com/apache/httpd/blob/trunk/modules/filters/mod_reqtimeout.c#L293 Yeah, mod_reqtimeout is missing context and states transitions, that's why I was talking about better interaction. Btw, I'm not sure what the SSL_WANT_READ/WRITE semantics are in openssl/mod_ssl but with the async handshake we can either always poll() in the MPM before trying to actually read/write on the socket (which could be quite painful for usual cases), or first try to read/write and set the WANT_READ/WRITE flag afterward only if EAGAIN. AIUI, mod_ssl currently FLUSHes all the packets during handshake which means that writes can block still, how is that handled? Regards; Yann.
