QNetworkAcessManager::setTransferTimeout(): Why error == OperationCanceledError and not TimeoutError?

[Robert Hairgrove]

As of Qt 5.15, there are a couple of new member functions of QNetworkAccessManager: transferTimeout() and setTransferTimeout() which I am using to implement a user-defined timeout for network requests.

To test this, I have installed a PHP script which includes a call to sleep(50) to provoke my timeout which I set to 1000 ms in the client application.

This works; however, the error I receive from the finished() signal is QNetworkReply::OperationCanceledError and not QNetworkReply::TimeoutError.

Now I am wondering what the logic behind this is? Of course, if the timeout error is raised on the server, I assume that the error returned would be QNetworkReply::TimeoutError.

[Axel Spoerl]

Not knowing your code, it's a bit of guesswork. Probably, the connection is canceled with close() or abort(), when the reply's timeout kicks in. Those two methods cause QNetworkReply::OperationCanceled.

[Robert Hairgrove]

@Axel-Spoerl Thank you!

I found the place where it calls abort() in the source code (file: qnetworkreplyhttpimpl.cpp at line 2075):

void QNetworkReplyHttpImplPrivate::_q_transferTimedOut()
{
    Q_Q(QNetworkReplyHttpImpl);
    q->abort();
}

This is a slot which is connected to the timer used to set up the transferTimeout in the function QNetworkReplyHttpImplPrivate::setupTransferTimeout() which immediately follows the previous function in the source.

I wonder why the authors didn't call QNetworkReplyHttpImplPrivate::error() instead of abort()? Then the TimeoutError could have been specified.

It doesn't apply to the project I have currently, but I can imagine that there would be situations where a long-running network request could be canceled manually, by clicking a button, for example, and also have a timeout set. Then one could differentiate between the two.