On 05 Oct 2015, at 5:13 PM, Eric Covener <cove...@gmail.com> wrote: > It seems like > extending that to handlers (and implicitly, request filters) is more > the "can't be done" part.
Having had a chance to look at the handlers in more detail, I suspect the problem is that async support wasn’t extended far enough. You can return SUSPENDED from a handler, but only on the main request. If you’re in an internal redirect or a subrequest, SUSPENDED is treated as an error. Request filters are already asynchronous, they aren’t a problem. A caller can only take advantage of the async nature of the input filters if the caller itself is asynchronous. It should be possible to use an async input filter from an async output filter simply by changing the sense of the connection and letting the core deal with it. This is next for me, I plan to fix any bugs that stops this being possible. Regards, Graham —
