Re: Detecting client aborts and stream resets

2016-05-11 Thread Michael Kaufmann
Zitat von Stefan Eissing : Thanks for the patch! I applied it to trunk in r1743335, will be part of next 1.5.4 release. I only omitted the last change as I do not want to set aborted on the main connection every time the session closes. Ok, that's fine for me.

Re: Detecting client aborts and stream resets

2016-05-11 Thread Stefan Eissing
Thanks for the patch! I applied it to trunk in r1743335, will be part of next 1.5.4 release. I only omitted the last change as I do not want to set aborted on the main connection every time the session closes. Cheers, Stefan > Am 10.05.2016 um 14:37 schrieb Michael Kaufmann

Re: Detecting client aborts and stream resets

2016-05-10 Thread Michael Kaufmann
Zitat von William A Rowe Jr : On Wed, May 4, 2016 at 3:44 PM, Michael Kaufmann wrote: William is right, this is not a good idea. The ->aborted flag should serve this purpose of telling anyone interested that this connection is not longer

Re: Detecting client aborts and stream resets

2016-05-04 Thread William A Rowe Jr
On Wed, May 4, 2016 at 3:44 PM, Michael Kaufmann wrote: > William is right, this is not a good idea. The ->aborted flag should serve >> this purpose of telling anyone interested that this connection is not >> longer delivering. I will make a github release soon where

Re: Detecting client aborts and stream resets

2016-05-04 Thread Michael Kaufmann
William is right, this is not a good idea. The ->aborted flag should serve this purpose of telling anyone interested that this connection is not longer delivering. I will make a github release soon where that is working and you can test. Thank you Stefan! It is now working for stream

Re: Detecting client aborts and stream resets

2016-05-04 Thread William A Rowe Jr
On Tue, May 3, 2016 at 2:05 PM, Michael Kaufmann wrote: > 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,

Re: Detecting client aborts and stream resets

2016-05-04 Thread Stefan Eissing
> Am 03.05.2016 um 17:35 schrieb William A Rowe Jr : > > On Tue, May 3, 2016 at 9:31 AM, Michael Kaufmann > wrote: > Hi all, > > a content generator module can detect client aborts and stream resets while > it reads the request body. But how can

Re: Detecting client aborts and stream resets

2016-05-03 Thread Michael Kaufmann
Zitat von William A Rowe Jr : On Tue, May 3, 2016 at 9:31 AM, Michael Kaufmann wrote: Hi all, a content generator module can detect client aborts and stream resets while it reads the request body. But how can it detect this afterwards, while

Re: Detecting client aborts and stream resets

2016-05-03 Thread Mike Rumph
Hello Michael. On 5/3/2016 7:31 AM, Michael Kaufmann wrote: Hi all, a content generator module can detect client aborts and stream resets while it reads the request body. But how can it detect this afterwards, while the response is being generated? This is important for HTTP/2, because the

Re: Detecting client aborts and stream resets

2016-05-03 Thread William A Rowe Jr
On Tue, May 3, 2016 at 9:31 AM, Michael Kaufmann wrote: > Hi all, > > a content generator module can detect client aborts and stream resets > while it reads the request body. But how can it detect this afterwards, > while the response is being generated? > > This is

Detecting client aborts and stream resets

2016-05-03 Thread Michael Kaufmann
Hi all, a content generator module can detect client aborts and stream resets while it reads the request body. But how can it detect this afterwards, while the response is being generated? This is important for HTTP/2, because the client may reset a stream, and mod_http2 needs to wait