Back in the bad old days of WML,  redirection bugs with mobile browsers and WAP gateways were pretty common. Mobile web developers were urged to avoid using redirection.  If you think that’s no longer the case, think again.  I found what I believe is a nasty redirection bug with Sprint/Nextel’s iDen network. In spite of being really old technology and having a data rate of only 19.2 kbit/s, iDen is interesting to mobile web developers, at least in the U.S., because it’s the network used by Sprint’s hot selling $50/month Boost Mobile Unlimited Prepaid plan which includes unlimited voice, SMS, Push to Talk and data.

Wapreview.mobi traffic is up lately and I noticed that page load times have increased a bit.  I decided to implement page caching to see if I can speed it up. I use browser detection and adapt page and image sizes for different classes of browsers. I divide browsers into four classes so there are four different versions of each page.

Instead of generating each page on the fly for every request, I recently added some code to detect the browser and use a server side redirect to one of four different pre-built versions of the requested page.  I used a query string parameter to specify each of the four page variants.  So a request for http://wapreview.mobi is redirected to http://wapreview.mobi?sid=class, where sid is either wap, full, max or ip depending of the browser.  I use PHP and Apache to send  a 302  “Found” header and  specify the fully qualified path in the Location header which should work in all browsers.

Initially the new code seemed to be working well with a noticeable decrease in page load times and less load on the server.  Unfortunately, I also noticed that I could not open wapreview.mobi with handsets on Sprint/Nextel’s iDen network.  With the iDen phones attempting to load any page on the site failed with a HTTP 404 “Not Found Error”

I created some test pages with and without the redirection and also with redirection to different targets. I tested  three different phones (i776, i355 and i9) on the iDen network at a local Sprint shop.  With all three phones

• Redirection from wapreview.com to wapreview.mobi or wapreview.mobi/dir/ worked.
• Redirection from wapreview.mobi to wapreview.mobi/?sid=wap failed with a 404.
• Entering wapreview.mobi/?sid=wap directly in the browser worked.

Each of the three phones used a different version of the Openwave browser; 7.0.2.2.c.1.109, 7.0.2.2.c.1.110 or 7.2.7.2.520; but traffic to all three went though the same Openwave version 5.1.2.17 WAP gateway. I had no problem with the redirected  pages using phones with Openwave browsers on the AT&T and Verizon networks which use newer (6.3.0.0.0 and 6.2.3.2 respectively) versions of the  Openwave gateway.

My guess is Sprint’s older gateway is either buggy or misconfigured and can’t handle redirection from one uri to another if both have the same host and path and differ only in the query string.  I modified the wapreview.mobi caching code to eliminate the redirection and everything is working, even on iDen.

So even today, mobile web developers need to be wary of redirection.  Avoid it if possible, if nothing else it creates an extra round trip between the server and browser which can increase page load times.  In some cases, as I found,  it can even keep your site from loading.  If you must redirect, test on as many devices and networks as possible.