Skip to main content

Problem performing an HTTP Redirect on a Motorola SLVR L7 mobile WAP browser

I'm blogging about this in the hope that it can help anyone else who happens to get stuck with this same issue.

On Friday I was caught out by a very 'interesting' bug in the mobile (WAP) internet browser of a Motorola SLVR L7 handset.

We were attempting to perform an HTTP redirect from one WAP site to another on the SLVR but were receiving a "404 Page Not Found" error message. When we looked at the URL that the phone was attempting to redirect to it was a combination of the first site with a bit of the query string of the second site tacked on the end:

First WAP site:
Second WAP site: Holiday+Location-Mar+2007

Result of redirect:

We thought it might be the length of the URL, the number of parameters in the query string, or the fact that the sites were situated on different web servers. Mobile phone browsers are notorious for not fully supporting the HTTP stack and the Motorola SLVR was probably no exception. We resorted to slowly stripping out bits of the second URL hoping that at some point it would start to work.

We stripped all the parameters off the end of the second URL and that resulted in a successful redirection to the correct server. We then added the parameters back on and found that when we added the "title" parameter it failed. After a little more experimentation we discovered that the source of the problem was the word "Location" found in the value of the title parameter!

"Location" didn't work but "location" did...

Here's the reason why, take a look at this HTTP redirection header sent from the first server to the handset:

HTTP/1.x 302 Moved Temporarily
Date: XXXX
Server: XXXX
Location: Holiday+Location-Mar+2007
...other HTTP headers...

The word "Location" occurs twice, once as a true HTTP header field and once as text in a URL.

Our guess is that the SLVR's browser code is a rather sloppy in how it detects and handles HTTP redirects and rather than looking for "Location" at the beginning of the line it matches the last one that it can find - hence the rather strange "-Mar+2007" on the end of the first URL!

Technorati Tags: , , , , ,


Anonymous said…
Reminds me of a problem I had back in 1998 or so, with an app that passed a parameter called "currentgroup" to most pages. Under the current common version of IE at the time, the URLs would be oddly mangled with what looked like binary garbage appearing in them.

It turned out, of course, that ...¤... from where the currentgroup param was specified in the URL was being turned into an international currency symbol - ¤, ¤ in HTML. IE was parsing it as a character entity in the URL, despite the lack of trailing semicolon...
Andrew Beacock said…
Alaric, I think you did pretty well to solve that issue as well! Sounds like a pretty nasty bug, how long did it take you to figure that one out?