Following the guidelines regarding the memory management of the request object in the docs:

QHttpRequest is never deleted by QHttpServer. Since it is not possible to determine till what point the application may want access to its data, it is up to the application to delete it. A recommended way to handle this is to create a new responder object for every request and to delete the request in that object's destructor. The object itself can be deleted by connecting to QHttpResponse's done() slot as explained below.

When on a browser that supports keep-alive connections, the closing of the connection will cause a segfault in the MOC file for the QHttpConnection, as shown below:

This segfault occurs because the open connection handles multiple requests, and they are each deleted using the QObject::deleteLater() slot attached to the QHttpRequest::done() signal. The problem occurs when the keep-alive connection is finally closed. The current request will most likely have already been deleted, but then the connection being closed calls the end() slot on it right here:

if (m_request) {
    if (m_request->successful())
        return;

    m_request->setSuccessful(false);
    Q_EMIT m_request->end();
}

Even if the request itself was successful, it seems that the deleting of the request invalidates that memory and the call to QHttpRequest::successful() will sometimes return false, causing the Q_EMIT to occur. I used Chrome for testing my current application and it seemed very strange to me that the application would (very unconsistently) crash after sitting for about 5 minutes! It was only after I noticed that the crashes often occured after closing the browser completely.

The presented fix is simple and will simply attach a slot to the QObject::destroyed signal. We can use this to complete the request if not successful set the request to NULL. This invalidateRequest function can now also be used in the connection closed handler.