We had an interesting problem to solve recently for one of our customers. Some users were reporting that the mobile site had stopped working for them a few clicks in, whereas the mobile site worked fine for most other users, so the issue seemed sporadic. At first, the team was focused on a potential firewall issue or cache at Akamai, but through extended testing, we were finally able to narrow the issue down specifically to users on the Sprint LTE network.
One of the interesting things was that, for any of these users, if their phone was connected to a WIFI network, the mobile site worked fine since their HTTP traffic was streaming via the WIFI connection. But as soon as they turned WIFI off and were streaming via their 4G connection, the site stopped working again after a few clicks.
Our initial conclusion was that something was cached poorly on the Sprint LTE network itself, but this answer was unsatisfying because it left us with no idea on what might being cached incorrectly, or any path to resolve how long something like that may take to clear up. So, we decided to keep digging.
A challenge of diagnosing traffic on phone devices specifically (and in this case, the iPhone), can be getting detailed information about response headers, viewing the HTML source, etc. There are a lot of great tools for doing this on desktop browsers, such as the Firebug plug-in for Firefox, but normally you can’t get any of this information using Safari on your iPhone.
One of our partners at the hosting company then suggested using a utility called “HTTPWatch” available in the Apple App store. We started with the basic (free version), which will give some statistics for headers, but does not allow you to view the source unless it is a common domain (such as Google). However, what it could tell us was content size of the HTTP response, and by comparing the size of a page request three clicks in for a user on the Sprint LTE network, and a user on a different network, we instantly had a breakthrough. For the user on a WIFI or other cell phone network, the response size was 15 KB – however, for the user on the Sprint LTE network, the response size was 566 KB! In fact, for the first three clicks of the site (homepage, category navigation, category), the sizes were 1 KB, 15 KB, and 15 KB for the first user, but 572 KB, 565 KB, and 566 KB for the user on the Sprint LTE 4G network.
This was an intriguing enough result that we wanted to know exactly what was going on. Given the amount of time we were burning on the issue, purchasing the full version of HTTPWatch for two users (price $99.99 each) was a no-brainer. Once downloaded, we were able to capture the full HTML response, save it, and do a comparison between each file to see what was going on, and then we had our answer – it appears that, for each request on the Sprint LTE network, the response was getting reformatted to include a number of resources such as CSS and JS files inline in the response!
This is bad for a number of reasons:
So, now we had our culprit, but didn’t know what to do about it. After some more research, one of our partners at our client found the following link on StackOverflow that ultimately provided the solution:
It seemed that the mobile UK operator O2 was doing something similar, but responded to an inquiry stating that they would honor the response cache header of “no-transform” if sent and their web proxy would not attempt to reformat the page.
The solution was to add the response header in Apache in the HTTPD config file:
Header set Cache-Control “no-transform”
The Sprint LTE network will honor this, and not attempt to re-write the page. This must be added as a response header (it can’t just be added as META tag) for it to be honored, which means adding at the Apache/Web Server (or Akamai/CDN) level.
For those interested, you can read more about the HTTP specification for the no-transform header here: