On 15/10/2015 00:29, Greg Wilkins wrote:
> I think there is some more HTTP2 features we should consider for the 4.0
> release.
>
> Unlike HTTP/1 it is possible for a HTTP/2 server to know if a connection
> has failed or if an individual stream has been reset before normal
> completion. This gives the possibility of adding listeners that
> can inform an application that their transport is no longer functional.
>
> Typically this would be useful if an application has dispatched an
> expensive and/or long running request handling process. With HTTP/1
> servers, it is not generally possible to know if the connection has been
> closed without actually attempting IO on it, so even if a client has
> long ago closed the connection, the first that the expensive/long
> request handler will know about it is when it completes and attempts to
> write the response.
>
> With HTTP/2, the connection is always IO active (as it is multiplexed),
> so any connection failures will be hungrily discovered with a read
> IOException. There are also explicit frames available to allow a
> particular stream to be reset.
>
> Thus there is now scope to provide a listener API that will be called if
> either a connection or request failure is detected.
>
> First quick thought for how this could be done would be to add a method
> on ServletRequestListener:
>
> default void requestCancelled(ServletRequestEvent sre) {}
>
> This call would have no affect on the normal request lifecycle and would
> be purely a notification that the underlying transport has been
> closed/cancelled/failed/shutdown. It would be up to the application
> to decide what (if anything) can be done about that.
>
> HTTP/1 containers would be free to make a best effort attempt to call
> this listener when appropriate, but typically this would only be
> possible in catastrophic situations (or else the server is exposed to
> DOS attacks by reading and buffering in order to seek IOExceptions).
>
> Thoughts?
+1.
I like it.
We get regular questions about this sort of thing on the users mailing
list. To date the response has always been "You have to wait for the I/O
to fail and handle it then." It would be great to have a better, spec
backed answer.
Mark