[Development] "foo" and the qnetworkdiskcache failure

Thiago Macieira thiago.macieira at intel.com
Wed Mar 4 02:48:32 CET 2015

Short story:

I think the current CI failure in 5.5 is fixed by 

Long story:

tst_qnetworkdiskcache has been trying to fetch pages from "www.foo.com", which 
is a real domain. It's possible that that the infrastructure for this domain 
changed recently, causing timeouts for us.

In the future, please be very careful about domain names, IP addresses, and 
port numbers in unit tests. If you're reviewing code from others, please try 
to validate the assumption with an eye towards the future.

Things you should avoid:
 - hardcoded host names that we can't control
	some unit tests tried to connect to "foo" port 80, which was fine in 
	Trolltech but promptly started failing once we ran tests in the Nokia 
	network. Similarly to www.foo.com now
	use invalid.test.qt-project.org" or localhost with a bad port number if 
	you'll try to connect; "example.com" is fine if your code will never 

 - hardcoded IP addresses
	When APNIC tried to delegate the network to a real customer, 
	they discovered a huge amount of traffic due to people using "" as a 
	test address. For that reason, the and networks are 
	blackholes (bogon)
	Use the IP addresses reserved by RFC 1166/5737, like

 - hardcoded port numbers (including default numbers)
	One of our tests tried to bind to port 1234, assuming it would never be 
	in use. Of course, there was a situation in which it was in use. Most 
	likely, it's a previous run of the test that failed to exit properly, so 
	the port was still lingering open by the OS.
	If you're going to open a socket, always use port number 0, which will 
	ask the OS assign an unused port to you (use QTcpServer::serverPort() or
	QUdpSocket::localPort() to get it).
	If you're going to connect and expect it to fail, choose a very low port 
	number, like 4, which is unassigned.

 - connecting to outside the test network
	Trying to connect to qt-project.org and check the result of those pages. 
	Not only can the content change unpredictably, corporate firewalls may 
	block the access.
	Either use a mini HTTP server bound to localhost or use the network test 

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list