Section 508

November 5th, 2013

Using the No Transform Header

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:

  •  It bloats the size of the HTML response page to the end customer’s phone.  One of the benefits of having  Javascript and CSS            includes (aside from global re-usability) is that a browser will download once, and can then reuse, thus reducing the size of            subsequent requests.  By putting this in line in every request, it was increasing the page size by a factor of 10X
  •  Some Javascript statements that work fine as a “js” include file may not work so well when converted to inline Javascript.                Specifically in this case, a Google Javascript plug-in was using a document.write() statement that, once changed to inline,                broke the processing on the category page for the mobile framework

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:

Now that most modern websites have any number of third-party Javascript plug-ins, it is our recommendation to start using this response header as a best practice for both mobile and normal desktop sites as well (since many users will choose to browse the full site using their tablet devices on a 4G network as well).   For customers using a third party proxy to transform their desktop site into a mobile site such as Usablenet or Moovweb, you may need to consult with them first on the best use of this response header.

Tags: 24x7 Mobility Solution and App Management Corrective Maintenance Managed Mobility Services Operations and Maintenance UX, Web & App Development

Connect with us

Job Openings

Want to be part of our growing team?

View More
Work with us

Learn how DMI can help you grow, or launch your business.

Get In Touch

See all of our locations around the world

View Locations