AW: async mod_proxy_http
> -----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?
> > Why now doing ap_mpm_resume_suspended after
> > ap_finalize_request_protocol(baton->r) and
> > ap_process_request_after_handler(baton->r)?
> I think we don't want EOS/EOR filtering race with the MPM on the