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?
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com