> -----Ursprüngliche Nachricht----- > Von: Yann Ylavic <ylavic....@gmail.com> > Gesendet: Donnerstag, 13. September 2018 12:24 > An: httpd-dev <dev@httpd.apache.org> > Betreff: Re: async mod_proxy_http > > On Thu, Sep 13, 2018 at 10:55 AM Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com> wrote: > > > > > -----Ursprüngliche Nachricht----- > > > Von: Yann Ylavic <ylavic....@gmail.com> > > > Gesendet: Donnerstag, 13. September 2018 10:37 > > > An: httpd-dev <dev@httpd.apache.org> > > > Betreff: Re: async mod_proxy_http > > > > > > On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group > > > <ruediger.pl...@vodafone.com> wrote: > > > > > > > > I don't like the "misuse" of c->aborted here. I for instance log > in > > > > the access log whether connections have been aborted or not and > this > > > > approach would mean that all proxied websocket connections would > get > > > > marked as aborted. Can't we use any other flag to tell the MPM to > > > > close the socket and push the pool, e.g. a note in c->notes? > > > > Why is the lingering close no longer needed? > > > > > > Agreed, let lingering close do its job if the client connection is > not > > > closed already. > > > Better in v2 (attached)? > > > > Better. Should a module outside the core directly fiddle around with > > the connection state in this case setting it to CONN_STATE_LINGER? > > I'd said no... but for modules playing async with the MPM :p > One way or another we need a flag which is meant for the MPM at > resume_suspended time (be it the state, a c->notes, ...), and that > hook is likely to be called by modules going async...
So we lack some clearly defined API here? If yes shouldn't one defined? Regards Rüdiger
