Qantas's Multi-city flights - Is (Stuck) Loading …
For months Qantas’s Multi-city flights page has been stuck showing a “Is Loading…” label. The page never finishes loading and I can not search for flights. The rest of the web site seems to work but not this critical page.
I presumed it was likely to be because of local content or domain name system blocking software. Upon further investigating it seems to be a Content Delivery Network (CDN) error. This is a type of bug I have not knowingly encountered before, so I became curious.
As an initial check, I disabled all the content and domain name filters and tried again. The stuck page remained.
I also ruled out the usual set of variables, such as browsers, devices, caches, and the like. The stuck page remained.
I tried browsing the page from other Internet connections. From these connections the page worked as expected. This included from a mobile network which is provided by the same company as my wired connection.
So, the problem appears limited to my wired Internet connection.
I say stuck, but the underlying problem is a handful of page resources failing to load. All the failing resources are hosted on https://cdn.qantasloyalty.com. An example URL being https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js.
Fetching this resource with curl returns an error:
$ curl 'https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js'
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
A little searching suggests this error is server side. If so there is nothing I can reasonably do.
I wanted to understand if this problem would be solved by using the same servers that work when the browsed from elsewhere. That led me to learning new arguments for curl which appear below.
First I needed the Internet Protocol (IP) addresses of the servers.
Resolving the domain from the wired connection gives a CNAME record, which resolves to two A (IPv4) records:
$ dig cdn.qantasloyalty.com
…
;; ANSWER SECTION:
cdn.qantasloyalty.com. 2991 IN CNAME cdn.qantasloyalty.com.edgekey.net.
cdn.qantasloyalty.com.edgekey.net. 300 IN CNAME e172057.x.akamaiedge.net.
e172057.x.akamaiedge.net. 20 IN A 96.16.249.14
e172057.x.akamaiedge.net. 20 IN A 96.16.249.10
Resolving the domain on another Internet connection returns different IPv4 addresses:
$ nslookup cdn.qantasloyalty.com
…
Non-authoritative answer:
cdn.qantasloyalty.com canonical name = cdn.qantasloyalty.com.edgekey.net
cdn.qantasloyalty.com.edgekey.net canonical name = e172057.x.akamaiedge.net
Name: e172057.x.akamaiedge.net
Address: 92.123.104.50
Name: e172057.x.akamaiedge.net
Address: 92.123.104.44
The difference in resolved IPv4 addresses is reasonable and expected. The Content Delivery Network is spreading out the requests geographically and by demand to different (hopefully) identically configured servers.
We can use curl to send our request to a server by IP address and bypass the domain name look-up. This avoids the CDN determining which server responds to our request.
To work, the request also needs to tell the IP addressed server which domain name we think it is representing. A CDN server is likely handling many domain names. The hostname is also critical for Transport Layer Security (TLS) to secure the connection.
First let’s try the two wired Internet addresses. These are expected to fail:
$ curl --resolve cdn.qantasloyalty.com:443:96.16.249.14 'https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js'
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
$ curl --resolve cdn.qantasloyalty.com:443:96.16.249.10 'https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js'
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
As expected, they failed with the same server side error. Next let’s try using the IP addresses returned to the working connection but on the wired failing connection:
$ curl --resolve cdn.qantasloyalty.com:443:92.123.104.50 'https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js'
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
$ curl --resolve cdn.qantasloyalty.com:443:92.123.104.44 'https://cdn.qantasloyalty.com/appcache/qdd-login-ribbon/master/0.0.0/bundle.js'
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
Disappointingly these requests also failed.
I have no idea who to report this problem to.