httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Detecting client aborts and stream resets
Date Wed, 04 May 2016 17:52:43 GMT
On Tue, May 3, 2016 at 2:05 PM, Michael Kaufmann <>

> Zitat von William A Rowe Jr <>:
>> 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
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
be the wrong interface. You want an interface that would test/report "gone
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
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.

View raw message