[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: async mod_proxy_http



> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <ylavic.dev@xxxxxxxxx>
> Gesendet: Donnerstag, 13. September 2018 12:24
> An: httpd-dev <dev@xxxxxxxxxxxxxxxx>
> Betreff: Re: async mod_proxy_http
> 
> On Thu, Sep 13, 2018 at 10:55 AM Plüm, Rüdiger, Vodafone Group
> <ruediger.pluem@xxxxxxxxxxxx> wrote:
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Yann Ylavic <ylavic.dev@xxxxxxxxx>
> > > Gesendet: Donnerstag, 13. September 2018 10:37
> > > An: httpd-dev <dev@xxxxxxxxxxxxxxxx>
> > > Betreff: Re: async mod_proxy_http
> > >
> > > On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
> > > <ruediger.pluem@xxxxxxxxxxxx> 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