On Tue, May 3, 2016 at 2:05 PM, Michael Kaufmann <m...@michael-kaufmann.ch> wrote:
> Zitat von William A Rowe Jr <wr...@rowe-clan.net>: > >> >> Nope - an optional function in mod_http2 is too special case, generators >> must remain protocol (socket or other transport) agnostic. >> > > Sure, official Apache modules should not call protocol-dependent hooks, > but it could be a solution for 3rd party modules. Nonsense, third party module designers should be equally aware - when you start meddling in unexpected edge cases, binary ABI won't be maintained in those edge cases. You are always better off relying on the intended design of httpd, unless you want to chase a moving target. Extending this detection with a protocol-agnostic API would be interesting, however an optional function has only a single registered provider, so it would be the wrong interface. You want an interface that would test/report "gone away" irrespective of http1 vs http2 vs future protocols. > In the case of mod_cache'd content, the generator can't quit, it is already >> populating a cache, which means you'll generate an invalid cached object. >> >> But if you knew that the cache module wasn't collecting info, >> r->c->aborted >> tells you if anyone is still listening, right? >> > > Unfortunately not. While the content generator is running (just preparing > the response, it is not reading from the input filters anymore and not > writing to the output filters yet), Apache does not check the connection's > state. > Good point... where/how would we address this for CPU intensive generators? We certainly don't bother in proxy, because proxy is much lighter-weight. The obvious answer to me in a worker or event MPM would be for the user to make a 'notify close?' request to the MPM, which would add the socket with for the POLLHUP event alone after reading the input brigade (the read will signal r->c->aborted already), with the single goal of setting the flag r->c->aborted upon socket close. Very lightweight, but that presumes that a second poll on the same fd for different events (e.g. poll on read or write) elsewhere won't give the kernel conniptions. mod_http2 has enough going on the master connection that detecting the stream close should occur fairly promptly.
