[General Topics] Menneisyys:
There was another test I’ve made (you can do the same too), which is listed in the last (“Takes into account last URL part? (Not usable with, say, servlets!)”) column. If you supply an additional path information to the URL (in the form of, say, http://test-PC-address:82/bogusfilename.bogusextension), fooling the Web browser into thinking it’s requesting a file off the server with the filename bogusfilename.bogusextension, you can test whether it tries to set the name and the type of the saved file based on this information.

THE CHART IS HERE - CLICK THE LINK!

Note that C-D stands for the Content-Disposition HTTP response header, which tells the client (in the "Attachment" property) what filename a given, dynamically served and/or generated file (that is, one whose name can't necessarily be guessed from the request URL sent by the client) should be saved at. (See this for more info.) Unfortunately, Opera Mobile (unlike the desktop brother) just ignores this header; this is why it doesn't know under what name a given file should be saved at.

3.5.	Summary chart: the differences between desktop and mobile versions

Now that we've seen the Pocket PC-based and the desktop Opera and Internet Explorer are different in some respects even on the protocol level, let's have a summary of these differences. This will be of great help to Web authors wanting to make sure their Web contents are accessible by both desktop and Windows Mobile clients:

avoid only relying on the client's ability to get the filename off the C-D HTTP request header of dynamically created files: try to use a bogus filename at the end of the invoking URL because it's from there that Opera Mobile tries to extract the filename from

upon receiving double requests in rapid succession for a given resource, don't return an error page (instead of the requested resource) to the second request but return with the same resource (the RapidShare problem with NetFront and Opera Mobile)

never use the text/plain type because it'll make PIE / IEM and NetFront try to render the page without actually checking for being binary. Even application/octet-stream should be avoided (use application/SOME-UNKNOWN-TYPE instead) if you don't want PIE / IEM to try to even peek into the file to find out what type it is. Try to keep your MIME type configuration as up-to-date as possible and make sure you include file extensions of all binary types you or your users put on your / their homepage(s).

THE CHART IS HERE - CLICK THE LINK!

It's worth pointing out that the desktop Mozilla / Firefox and the Pocket PC Minimo work exactly the same way in every respect - as has always been the case. Great, promising work - certainly the dream of webmasters sick of profoundly different desktop and mobile versions!

4.	Recommended links

The Web Browsers category on my blog

How can you avoid the consequences of a new, file download-related bug I've just found in Pocket Internet Explorer? - now deprecated

Beware of downloading large files straight to memory cards, even over fast connections! It can take ages! - now deprecated

Downloading files with PIE (alternatives: PPCT, AximSite, PPC Magazine, FirstLoox, BrightHand). (Pretty outdated!)

Do you know ftxPBrowser? - somewhat deprecated: no WM5-related compatibility info; however, it provides a good overview of the features of the browser

Here's how you can save images from inside best Pocket PC Web Browser, Opera Mobile! - still topical

New version 1.06 of Great Alternate Web Browser NetFront is out! A full review - with some page loading / rendering data

Link collection to the latest Pocket PC Web Browser reviews (will update some time)

Relocating the Pocket Internet Explorer / NetFront cache (alternatives: PPCMag, iPAQ HQ, AximSite, FirstLoox, BrightHand)

Bible of Web Browsers (alternatives: MobilitySite, AximSite, FirstLoox, PPC Magazine, BrightHand) – over a year old, but still contains topical info

UPDATE (10/14/2006): PPCT frontpage; added an explanation of the HTTP server emulator.