The timeout for Servlet 3.0 async requests is defined roughly as the time between ServletRequest#startAsync and calls to either AsyncContext#dispatch or AsyncContext#complete.
In WebFlux we call ServletRequest#startAsync automatically and then use Servlet 3.1 non-blocking I/O with AsyncContext#complete at the end. The dispatch does not fit into our processing model which is not based on the Servlet API to begin with and we call startAsync quite early, way before we could know if the request will require streaming or not.
For now our only option is to set the AsyncContext to never time out (-1) in order to make streaming scenarios possible. The downside is the lack of protection for non-streaming requests but then again even in the Servlet API there is no protection against regular requests taking indefinitely to process.
It should also be noted that both Reactor and RxJava provide timeout operators so that's something natural to express. In the future we can consider implementing a timeout feature that's built into the Spring WebFlux processing model and works across all runtimes. For example a timeout composed on the Mono<Void> returned from the HttpHandler.
Affects: 5.0 M5
#20228 Disable Servlet request async timeout for reactive type streaming scenarios in Spring MVC