# Sunday, March 16, 2008

One of my colleagues faced a interesting problem with a mobile web portal their team made recently. While other phones could log into the web site without any problems, a few Nokia Series 60 (S60) phones like the N73 the client was testing with couldn't. And the phone just fails with a typical Page Not Found error message, which in my experience it could be one of many things ranging from the fact that the page really couldn't be found, to XHTML tags which the phone couldn't recognize, to server errors. It's as if the phone makers deem error messages too much information to give to their users.

After writing web pages for mobile phones for a while you get to know a few things, two of the most important ones are. The phone hates you, and will always fail on things which you least expect it to. And the 2nd being, debuging problematic web portals are bloody hard, and the fact that the site only fails on the device which you have no way of installing a debugger on doesn't help.

So I decided to help my colleague with this interesting problem. He had already nailed down a few things.

  1. The login page works, on other phones, browsing via a desktop web browser, there's nothing wrong with the code.
  2. Even though he couldn't run a trace on the phone, he could run one on the web server. When the phone requested for the page the server logged the request, but when the LOGIN button was clicked. The server didn't receive a request.

The first thing I did was to run through the process of getting to the login page and logging in, sure enough everything worked up to the point of hitting the LOGIN button.

Next in order to take the fact that it could be a communications problem, I activated the N73 web browser in what I like to call FULL BROWSER MODE, the recent Nokia S60 phones have 2 web browser modes.

  • The first is what I call XHTML Compatibility mode, in this mode the on screen text are large, and the phone just behaves as if it's a more expensive lower end mobile phone. In this mode the browser is pretty strict about the pages it can view, it'll usually enforce proper XHTML rules, ie. tags need to be closed, case dependant, etc. etc. This is the typical mode a normal user starts the phone's browser in it seems. As far as I know, this mode is activated by holding down the 0 button on the phone.
  • The 2nd mode is activated by clicking on the Globe icon on the phone's start screen. In this mode the web browser displays everything as if it's a normal desktop browser, and like a normal browser it's less anal about the pages it can view, and will forget about tag casing.. closing, etc. etc. The easier way to identify this mode is that there's a mouse cursor on the screen when you're browsing in this mode.

(I realise there are probably PROPER names for the modes but hey... I don't know them)

So I hit the login page in full browser mode and viola... IT WORKED! So therefore the phone is capable of completing the request, just not in the normal XHTML mode. It was time to do some more sniffing around, usually I would think there was something wrong with the contents of the page the button POST'ed to but the FORM tag's ACTION tag read /mysite/thesamepage.aspx so basically it was posting back to itself, and the page itself was displaying properly.

Now that I knew the page was ok, it was time to look at other possible causes of the problem. As I mentioned before, in XHTML mode the browser is very strict about following web protocol rules, guidelines, etc. etc. So since we know that the PAGE is ok, the next place to check was the HEADERS which the server was sending to the browser. This was easy thanks to the fact that we could hit the page with the desktop. And there in the headers I saw this value which I didn't usually see.

Content-Location:http://someinternal-server.com:555/template.aspx

A quick search turned up this definitions page (it's near the middle, so do a find for content-location once you get there)

What caught my eye was this line in the document : The value of Content-Location also defines the base URI for the entity.

Hmm.. wouldn't that mean that the base URL for the document would be http://someinternal-server.com:555/ instead of the proper http://www.mypage.com/?

I checked the page in the phone again, in XHTML mode, the title image could not be displayed, in full web mode the image worked perfectly. The SRC for the image was a relative URL. ie: images/title.gif.

That's when I stumbled on the List Links function in the browser (I can't remember the exact name right now cause I don't have the phone with me, but it's basically under the more menu item) This showed a list of links on the page according to the browser, FULLY expanded links if they were relative ones. And sure enough.. a relative link such as /register/default.aspx was being interpreted on the phone as http://someinternal-server.com:555/register/default.aspx instead of the correct http://www.mypage.com/register/default.aspx. So basically, a simple header which normal browsers ignore, and according to the HTTP specs is pretty much optional is causing a whole lot of grief on a phone that feels like following every rule in the book.

The question now was why is the Content-Location pointing to a private address anyway? My colleague had the answer to that question already, the web server was sitting behind a... Reverse Proxy device in order to make the system more secure from intruders and probably was issuing requests to the web server in a private context.

It was now an infra problem, not a programming one.

The main point of this super long post? If you write pages that are to be viewed on mobile phones, be ready to be faced with all sorts of weird problems, some of them might be easy to spot, some of them not so much.


Note that you can Post As GUEST as well.
blog comments powered by Disqus