Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QNetworkReply fails with socket timeout for URLs that otherwise work
Red Baron last edited by Red Baron
Recently I've started looking into the QtNetwork module since it's part of a project I'm currently working on at work.
Then I moved to something that is closer to my own task. Basically I need to request data using HTTP GET requests (basically what
QNetworkAccessManager::get(...)does). These requests also include parameters. So I looked online for free HTTP GET request services and found
http://httpbin.org/xml(gives me some XML output that is similar to what I need to handle; other entpoints are available too) and later
In the demo application as well as my own (basically the same but for console) the first one leads to a socket timeout while the second one works without any issues.
Further both URLs work without a problem in Firefox (and its Http Requester add-on) and
curl --request GET --url "URL here"). This problem applies to many other URLs I've tried (that include parameters) including the one I'm supposed to use (I can't post it here).
I haven't worked with the QtNetwork module for a long time but even when I used it I don't recall having such a problem. Same applies for using HTTP requests. Am I missing something here? I've even tried to call these URLs with Python's
import urllib.request res = urllib.request.urlopen("http://httpbin.org/get").read().decode("utf-8") import xml.etree.ElementTree as ET doc = ET.fromstring(res)
and it just works.
Red Baron last edited by
I forgot to mention that I'm behind a proxy. A colleague of mine tried adding
httpso that the proxy and its caching is circumvented and it worked all of a sudden. Setting the raw header didn't help either. So basically for the target system (after it gets installed in the final product) I can work with the URL but on my PC behind the proxy I'm screwed and have to convert every single URL to
httpseven if it's not.
My colleague found that
QNetworkProxyFactory::setUseSystemConfiguration(true)does the trick in a very neutral way and it works now.