Prior to switching the protocol handler to use QHttp2Connection this particular issue (see bugreport) was not a problem because the handling of the IO-device being destroyed was simply to drop any pointer to it. QHttp2Stream, however, also has to keep track of the lifetime of the IO-device, because it needs to abort the stream if the data it's uploading is destroyed earlier than expected. Now, since QHttp2Stream might also have other errors come up, we have to connect to the generic 'errorOccurred' signal from it and handle whatever issues arise, notifying our users that the request for some reason cannot be fulfilled. It's thanks to this part that we were now, in certain cases, grabbing a stale pointer to the HttpNetworkReply and trying to call functions on it. We fix this somewhat indirectly. Because, after a HttpReply is destroyed, we shouldn't even have any references to it in the first place. And while it would usually be done as part of handling the deleted() signal, we actually disconnect from HttpNetworkReply's signals when we have processed one of the finished*() functions. But since we were still connected to the stream's signals we would still try to handle it. For the http1 protocol handler this was already handled in QHttpNetworkConnection::removeReply, which the HttpNetworkReply itself calls at start of destruction. The function will go through any place that the reply can be referenced and removes it. For http/2 it would remove it from the list of requests yet to be sent, but not from the in-progress list. So, we now add a new virtual function to the AbstractProtocolHandler and specialize it in Http2 to handle exactly this. Fixes: QTBUG-136549 Pick-to: 6.9.1 6.9 Change-Id: Ie41863677a3b163f77d10bc3904ca515f6840be3 Reviewed-by: Mate Barany <mate.barany@qt.io>