Important: Please read the Qt Code of Conduct -

Transfer timeout for GET requests is ignored, request gets canceled after 30s of data transfer

  • I am making a GET requests using QNetworkRequest and QNetworkAccessManager::get(). It works for fast requests on small data sets. But if the request takes longer then 30 seconds to complete it gets canceled. There are no problems with the connection and in that time data is being transferred. Network connection is slow and there is a lot of data so 30 seconds is just not enough to complete the requests.

    I've tried setting QNetworkAccessManager::setTransferTimeout to a larger value but that has no effect. I've also tried setting it using QNetworkRequest::setTransferTimeout but that did not compile to webasm with an error that there is no such method.
    Is there a way to control transfer timeout for requests from webasm?

    Right now I am using Qt 5.15 and Emscripten 1.39.8 as recommended in documentation.

  • Lifetime Qt Champion


    Is it the actual time passed to do the transfert or already at connection ?

  • The connection gets established almost instantly. 30 seconds is the actual time for data transfer. If I open the network tab in browsers developer console I see the request and I see that the actual data is constantly received. At exactly 30 seconds mark for this request it just stops.
    The actual data amount transferred during this time changes a bit depending on transfer speed.

  • Lifetime Qt Champion

    There's a connect timeout that you can set through QNetworkConfiguration but I currently don't remember whether it's also used for the rest of the operations.

  • Isn't that a different thing? Connection timeout is time given to establish a connection (and is even stated so in documentation). After a connection gets established connection timeout should not have effect on the active data transfer.
    In my case connection gets established in around 100 milliseconds.

    QNetworkRequest::setTransferTimeout seams like what I looking for, but values set here don't have any effect on the actual request. In a browser shouldn't the expected behavior of setting this be equal to something like setting XMLHttpRequest.timeout for JavaScript request?

  • Lifetime Qt Champion

    Yes it should but I was just thinking about some workaround for your use case.

    As for your second question, possibly yes but that I do not know.

    Maybe @lorn-potter might know.

  • Hi,

    Both QNetworkAccessManager::setTransferTimeout and QNetworkRequest::setTransferTimeout currently depend on Qt's 'http' feature, which WebAssembly does not use due to incompatibilities with the backend code, and that we implement the backend using javascript's XMLHttpRequest API because we do not have real sockets available for the 'http' backend to be fully functional.

    That said, I do have a patch that adds support for setTransferTimeout, but requires breaking those functions out of the #if QT_CONFIG(http) defines. I just uploaded it here:

    It currently uses QNetworkRequest::DefaultTransferTimeoutConstant

  • Thanks for the update. When can we expect this merged?

    Also why was QNetworkRequest::DefaultTransferTimeoutConstant used for default value? In the documentation if the function was never called the actual default value is stated to be 0 which is equal to no time limit. DefaultTransferTimeoutConstant is just used as default value if the function was called without any arguments.

Log in to reply