On Vista, do you use Internet Explorer? If so, have you tried using either Firefox or Opera on there, while using the Nokia connection, and seeing if you encounter the same intermittent issues? I'm suspecting this could be a Nokia network issue.
My reasoning is as follows:
GEEKERY ALERT
When a file is served over the web, it should have a header which specifies what kind of file it is (HTML, JavaScript, XML, whatever), e.g.
Code:
Content-Type: image/gif
The standard specifies that
"If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource." - RFC 2616 section 7.2.1
Firefox, Opera and IIRC Safari respect this portion of the standard. However Microsoft, back in the Nineties, either decided it knew better, or simply didn't read the standard properly, and
always attempts to deduce the media type by examining the content. This is a Bad Thing as it allows misconfigured servers and/or proxies to serve content with the wrong, or no, Content-Type header - but only to Internet Explorer. Browsers that follow the spec will then encounter precisely the kind of problems you describe.
I believe the issue is that one or more (but not all) of the proxy servers (or possibly routers) that Nokia channels your connection through is removing or mangling the Content-Type headers.
When you establish a connection via Nokia, one of the links in your connection to the web server to which your browser is making requests will be through one of Nokia's proxies. If that proxy is, for example, returning to you an XML file with a Content-Type header changed from "text/xml" to "text/plain", or if that file is returned with the Content-Type header removed altogether and its URL doesn't include the ".xml" extension, then Firefox (and I think Opera) will not recognise it as XML. I believe that GMail uses XML in Ajax calls behind the scenes to make things work, so this would cause it to fail.
Furthermore, JavaScript files served without a ".js" extension and so forth would not be interpreted as scripts.
My reasoning is based on the fact that you were offered the opportunity to save a response to a file of type ".php", rather than the content of the response being displayed. The steps would be as follows:
- Your browser sends a request for "http://www.example.com/example.php";
- The web server at "http://www.example.com/" executes the file "example.php" and sends the generated response with Content-Type "text/html";
- Nokia's network strips out the Content-Type header, meaning that there is no metadata describing the contents of the file as being HTML;
- Firefox, having no information as to what kind of content it has, looks at the name to see if it can guess from that;
- Seeing the name has the extension ".php" it checks the list of file types it knows how to display, but ".php" isn't on the list;
- It therefore concludes that this file is intended for another application, and offers to save it so you can then use it with that application.
This also explains why the problem is intermittent: you will be connecting to a different machine on Nokia's network each time you dial in, and if only some are misconfigured, it's the luck of the draw if you get one of them, or one that is operating correctly.
So I would suggest Nokia as being the root of the problem, not Ubuntu.
There are reasonably straightforward ways of debugging this problem in depth, at both the HTTP and TCP/IP level, such that you would be able to confirm my hypothesis and, if it is confirmed, assemble a partial list of IP addresses of misconfigured and properly configured Nokia proxies. However, you may well have better things to do with your time and prefer to take this to Nokia customer support instead.
I assume that Nokia have customer forums, so it might be worth checking them out for possibly related tales of woe, to bolster your case that their network is breaking the web and needs to be fixed.
HTH
Ubuntu Woes
Linear Mode
